Automatisch erzeugte Manpages.
Damit nicht jeder sphinx auf dem Rechner haben muss,
behalten wir bis auf weiteres die aus den .rst
erzeugten Manpoages auch im Repo.
Change-Id: Id556c0d11cf5f79659d8350952ce1c014d81ea44
diff --git a/doc/index b/doc/index
new file mode 100644
index 0000000..b2693f9
--- /dev/null
+++ b/doc/index
@@ -0,0 +1,21 @@
+
+Willkommen bei der Morgengrauen-Mudlib - Dokumentation!
+*******************************************************
+
+Inhalt:
+
+* sefuns (simulated efuns)
+
+* Properties
+
+* lfuns
+
+
+Indices and tables
+******************
+
+* *Index*
+
+* *Module Index*
+
+* *Search Page*
diff --git a/doc/lfun-liste b/doc/lfun-liste
new file mode 100644
index 0000000..63c3862
--- /dev/null
+++ b/doc/lfun-liste
@@ -0,0 +1,871 @@
+
+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/lfun.index b/doc/lfun.index
new file mode 100644
index 0000000..2018524
--- /dev/null
+++ b/doc/lfun.index
@@ -0,0 +1,20 @@
+
+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/lfun/AddAction b/doc/lfun/AddAction
index 23183ca..29c83c1 100644
--- a/doc/lfun/AddAction
+++ b/doc/lfun/AddAction
@@ -1,76 +1,104 @@
+
+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
+FUNKTION
+========
-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.
+ varargs void AddAction(mixed fun, mixed cmd, int flag, int lvl);
- 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.
+DEFINIERT IN
+============
- Das Kommando wird in P_LOCALCMDS eingetragen. Diese Property wird
- nicht gespeichert! Effektiv kann man mit AddAction() ein kommando-
- gebendes Objekt im Spieler einsparen.
+ /std/player/command.c
-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));
- ...
+ARGUMENTE
+=========
- // 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;
+ 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)
+
+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/lfun/AddAdjective b/doc/lfun/AddAdjective
index 6b58101..a96a5e5 100644
--- a/doc/lfun/AddAdjective
+++ b/doc/lfun/AddAdjective
@@ -1,39 +1,62 @@
+
AddAdjective()
+**************
-FUNKTION:
- void AddAdjective(string|string* adj);
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-ARGUMENTE:
- adj
- String oder Array von String mit den Adjektiven.
+ void AddAdjective(string|string* adj);
-BESCHREIBUNG:
- Zusaetzlich zu den mit AddId() vergebenen Bezeichnern laesst sich mit
- der Vergabe von Adjektiven die Ansprechbarkeit eines Objektes erhoehen.
-RUeCKGABEWERT:
- keiner
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Die Adjektive werden nicht dekliniert, man muss also fuer jeden
- sinnvollen Fall ein Adjektiv uebergeben.
+ /std/thing/description.c
-BEISPIELE:
- AddId( ({ "zettel", "blatt" }) );
- AddAdjective( ({ "kleinen", "kleines" }) );
+ARGUMENTE
+=========
- 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", ...
+ adj
+ String oder Array von String mit den Adjektiven.
-SIEHE AUCH:
- AddId(), RemoveAdjective() id(), present(), /std/thing/description.c
-----------------------------------------------------------------------------
+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/lfun/AddAmount b/doc/lfun/AddAmount
index 3be8e3f..59bb9b1 100644
--- a/doc/lfun/AddAmount
+++ b/doc/lfun/AddAmount
@@ -1,25 +1,44 @@
+
AddAmount()
+***********
-FUNKTION:
- void AddAmount(int menge);
-DEFINIERT IN:
- /std/unit.c
+FUNKTION
+========
-ARGUMENTE:
- menge
- Die Menge, die der Unit hinzugefuegt werden soll (kann auch
- negativ sein).
+ void AddAmount(int menge);
-BESCHREIBUNG:
- menge wird zur aktuellen Menge hinzugezaehlt. Sollte das Ergebnis 0
- werden, wird die Unit in absehbarer Zeit zerstoert.
-RUeCKGABEWERT:
- keiner
+DEFINIERT IN
+============
-SIEHE AUCH:
- /std/unit.c
+ /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/lfun/AddClass b/doc/lfun/AddClass
index f97730c..fee72e3 100644
--- a/doc/lfun/AddClass
+++ b/doc/lfun/AddClass
@@ -1,28 +1,48 @@
+
AddClass()
-FUNKTION:
- void AddClass(string|string* class);
+**********
-DEFINIERT IN:
- /std/thing/description.c
-ARGUMENTE:
- string/string* class - String oder Stringarray der Klasse(n)
+FUNKTION
+========
-BESCHREIBUNG:
- Dem Objekt werden weitere Klassifizierungen hinzugefuegt.
+ void AddClass(string|string* class);
- 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).
+DEFINIERT IN
+============
- Bitte prueft eure Objekte (NPCs, Krankheiten, Gifte, ...) auf korrekte
- Klassifizierung.
+ /std/thing/description.c
-SIEHE AUCH:
- RemoveClass(), is_class_member()
- P_CLASS
+
+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/lfun/AddCmd b/doc/lfun/AddCmd
index aeea8db..088da28 100644
--- a/doc/lfun/AddCmd
+++ b/doc/lfun/AddCmd
@@ -1,210 +1,244 @@
+
+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?");
+FUNKTION
+========
- a) "klett"
- b) "kletter"
- c) "klettere hoch"
+ varargs void AddCmd(mixed cmd, mixed func, [mixed flag, [mixed id]]);
- 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
+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: ganz simpel, beinahe wie add_action
+ AddCmd("befiehl","action_befehlen"); ... int action_befehlen(string
+ str) {
- // SIMPEL .. weitere Beispiele
- AddCmd(({"kletter","klettere"}),"action_klettern" );
- AddCmd(({"renn","renne"}),#'action_rennen);
+ if(!str || !strlen(str))
+ // Fehlermeldung, falls gar keine Funktion 1 dafuer
+ zurueckgibt notify_fail("Was willst du befehlen?!n");
- // REGELN: eine komplexere Regel
- AddCmd("loesch|loesche|ersticke&feuer|brand|flammen&decke|wolldecke",
- "action_loeschen",
- "Was willst du loeschen?|Womit willst du loeschen?");
+ 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
- // 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?");
+ } return 0; // MISSERFOLG - Fehlermeldung oben gesetzt
- // 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");
+ // SIMPEL .. weitere Beispiele
+ AddCmd(({"kletter","klettere"}),"action_klettern" );
+ AddCmd(({"renn","renne"}),#'action_rennen);
- // 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.");
+ // REGELN: eine komplexere Regel AddCmd("loesch|loesche|ersticke&f
+ euer|brand|flammen&decke|wolldecke",
-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)
+ "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/lfun/AddCmd_bsp b/doc/lfun/AddCmd_bsp
index 6a4e177..ec8ff17 100644
--- a/doc/lfun/AddCmd_bsp
+++ b/doc/lfun/AddCmd_bsp
@@ -1,320 +1,382 @@
+
+AddCmd_bsp()
+************
+
+
ADDCMD() - BEISPIELE
+====================
+
+
FUNKTION
- varargs void AddCmd(mixed cmd, mixed func, mixed flag);
+========
+
+ 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.
+===========
+
+ 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: 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);
+ // 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: 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?");
+ // 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);
+ // 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");
+ // 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
+ 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.");
+ // 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 1, OHNE REGELN ##
+ // bei Nichtverwendung von Regeln muss man Parameter selbst
+ auswerten AddCmd(({"bohr","bohre"}),#'action_bohren); ...
+ private int action_bohren(string str) {
- ## 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;
- }
+ 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 :)
- ## 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;
- }
+ if((j=member(tmp[(i+1)..],"in"))<0 &&
+ (j=member(tmp[(i+1)..],"durch"))<0)
- ## 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) ...
+ write("Willst Du das Loch in etwas bohren?n");
- ## 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) ...
+ else if((i=member(tmp[(j+1)..],"boden"))<0 &&
+ (i=member(tmp[(j+1)..],"erde"))<0)
- ## 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.");
+ write("In/Durch was willst du das Loch bohren?n");
- --- Ende Komplexbeispiel Regeln mit Fehlermeldungen ---
+ 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;
+ ## 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) {
- 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(....);
+ 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;
+
}
- 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;
- }
+ ## 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,
- --- Ende Komplexbeispiel Spezialregeln @PRESENT und @ID ---
+ "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.
+ // 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|hinauf|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?");
+ ## 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,
- // oder man versucht eine bessere Regel zu schaffen, was hier durch
- // die Moeglichkeit von zwei oder drei Parameter unmoeglich ist
+ "Wohin willst Du kriechen?");
- ## 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)
+ AddCmd("kriech|krieche&nach&oben",#'result_kriech,
+ "Wohin willst Du kriechen??|Wohin willst Du kriechen?");
- ## 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?");
+ AddCmd("kriech|krieche&aus&loch|grube|falle",#'result_kriech);
+ "Wohin willst Du kriechen?|Wohin willst Du kriechen?");
- // Da juengere AddCmd aelteren vorgehen, wird die komplexere Regel samt
- // ihrer Fehlermeldung nie ausgewertet, da ein "schlag ball hart" auch
- // die zweite Regel triggert.
+ // oder man versucht eine bessere Regel zu schaffen, was hier
+ durch // die Moeglichkeit von zwei oder drei Parameter
+ unmoeglich ist
- // 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?");
+ ## 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",
- // 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.
+ #'result_kriech, "Wohin willst Du kriechen?");
- AddCmd("schlag|schlage&@ID",#'action_schlag,
- "Was oder wen willst du wie @verben?");
- AddCmd("schlag|schlage&@ID&hart",#'action_schlag_hart);
+ ... static int result_kriech(string str, mixed >>*<<extra) {
- // Fast perfekt. Besser wird es nicht.
+ if(member(extra,"aus")>=0 &&
+ !sizeof(({str}),"*.\<(hoehle|grube|falle)\>.*"))
+ notify_fail("Woraus willst Du kriechen?n");
- --- Ende Komplexbeispiel mehrere Regeln ---
+ 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/lfun/AddDefender b/doc/lfun/AddDefender
index 3eb7923..5b33e14 100644
--- a/doc/lfun/AddDefender
+++ b/doc/lfun/AddDefender
@@ -1,34 +1,50 @@
+
AddDefender()
+*************
-FUNKTION:
- void AddDefender(object friend);
-DEFINIERT IN:
- /std/living/combat.c
+FUNKTION
+========
-ARGUMENTE:
- friend
- Objekt (normal Lebewesen), welches zukuenftig ueber Angriffe
- informiert werden soll oder diese sogar abwehrt.
+ void AddDefender(object friend);
-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
+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/lfun/AddDetail b/doc/lfun/AddDetail
index 229197b..951b48a 100644
--- a/doc/lfun/AddDetail
+++ b/doc/lfun/AddDetail
@@ -1,91 +1,110 @@
+
AddDetail()
+***********
-FUNKTION:
- void AddDetail(string|string* keys,
- string|string*|mapping|closure desc);
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-ARGUMENTE:
- keys
- String oder Array von Strings mit den Namen der Details.
- desc
- String, Mapping, String-Array oder Closure mit/zur Beschreibung.
+ void AddDetail(string|string* keys,
+ string|string*|mapping|closure desc);
-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.
+DEFINIERT IN
+============
- Fuer Details koennen Forscherpunkte eingetragen werden.
+ /std/thing/description.c
-BEISPIELE:
- Ein schlichtes Detail:
- AddDetail(({"sofa","couch"}), "Eine kleine Couch.\n");
+ARGUMENTE
+=========
- Laengere Details sollten hierbei nicht per Hand umgebrochen werden,
- sondern man kann hierzu die Funktion break_string() nutzen:
+ keys
+ String oder Array von Strings mit den Namen der Details.
+ desc
+ String, Mapping, String-Array oder Closure mit/zur Beschreibung.
- 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:
+BESCHREIBUNG
+============
- AddDetail(({"bett","bettchen"}),
- ([0 :"Eine kleines Bett.\n", // Der Defaulttext
- "zwerg": // Die Rasse klein schreiben
- "Das Bett laedt geradezu zu einem Nickerchen ein.\n"]));
+ 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", ...]).
- Und nun ein Detail mit Closure (diese Version ersetzt das Verhalten
- von AddSpecialDetail).
+ 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.
- 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";
- }
+ Fuer Details koennen Forscherpunkte eingetragen werden.
- 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()
+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/lfun/AddDrink b/doc/lfun/AddDrink
index 6b99e08..4d722ec 100644
--- a/doc/lfun/AddDrink
+++ b/doc/lfun/AddDrink
@@ -1,12 +1,18 @@
+
AddDrink()
+**********
-BEMERKUNGEN:
- Die Funktion AddDrink() sollte NICHT MEHR BENUTZT werden.
- Bitte AddToMenu() verwenden.
+BEMERKUNGEN
+===========
-SIEHE AUCH:
- AddToMenu(), RemoveFromMenu()
+ 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/lfun/AddExit b/doc/lfun/AddExit
index 9942ef3..384975f 100644
--- a/doc/lfun/AddExit
+++ b/doc/lfun/AddExit
@@ -1,91 +1,114 @@
+
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
+FUNKTION
+========
-BESCHREIBUNG:
+ void AddExit(string|string* cmd, closure|string dest);
- 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.
+DEFINIERT IN
+============
-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 "../..")
+ /std/room/exits
- Mittels P_HIDE_EXITS kann man Ausgaenge verstecken.
- Bei der Benutzung eines Ausgangs wird der Hook H_HOOK_EXIT_USE
- ausgeloest.
+ARGUMENTE
+=========
-BEISPIELE:
- ### normale Ausgaenge ###
- // Beim Kommando "sueden" kommt: "<name> geht nach Sueden."
- AddExit("sueden", "/gilden/abenteurer");
+ string/string* cmd
+ die Richtung(en), in die der Ausgang fuehrt
+ string/closure dest
+ das Ziel des Ausgangs mit Text/Closure
- // 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" );
+BESCHREIBUNG
+============
- // Und dieser nach "/d/inseln/anthea/anlege":
- AddExit("sueden", "../anthea/anlege" );
+ Es wird ein Ausgang in die Richtung(en) cmd eingefuegt. Die Art des
+ Ausgangs haengt ab von dest:
- ### dynamische Ausgaenge ###
- // ein Ausgang soll nur von Froeschen benutzbar sein:
+ - 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.
- 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");
+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
+
+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/lfun/AddExp b/doc/lfun/AddExp
index 8baed55..a8bf488 100644
--- a/doc/lfun/AddExp
+++ b/doc/lfun/AddExp
@@ -1,32 +1,56 @@
+
AddExp()
-FUNKTION:
- int AddExp(int e)
+********
-DEFINIERT IN:
- /std/living/life.c
-ARGUMENTE:
- int e - Anzahl der hinzuzufuegenden (abzuziehenden) XP
+FUNKTION
+========
-BESCHREIBUNG:
- Dem Living werden e XP auf seine bisherigen P_XP addiert.
+ int AddExp(int e)
- 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.
+DEFINIERT IN
+============
-BEMERKUNG:
- - positive und negative Werte sind moeglich
- - P_XP wird nicht <0 gesetzt.
+ /std/living/life.c
-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()
+ARGUMENTE
+=========
-14.Feb 2007 Gloinson
\ No newline at end of file
+ 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/lfun/AddExtraLook b/doc/lfun/AddExtraLook
index 526a851..7436f7e 100644
--- a/doc/lfun/AddExtraLook
+++ b/doc/lfun/AddExtraLook
@@ -1,96 +1,130 @@
+
AddExtraLook()
-varargs int AddExtraLook(string look, [int duration, string key,
- string lookende, object ob]);
-DEFINIERT IN:
+**************
+
+AddExtraLook() varargs int AddExtraLook(string look, [int duration,
+string key,
+
+ string lookende, object ob]);
+
+
+DEFINIERT IN
+============
+
/std/living/description.c
-BESCHREIBUNG:
+
+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.
+ARGUMENTE
+=========
-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.
+ - 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. ;-)
-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.
+RUECKGABEWERTE
+==============
- # Mit Objekt, was den Extralook und die Endemeldung dynamisch erzeugt
- living->AddExtraLook("get_my_special_extralook", 3600, 0,
- "extralookende", this_object());
+ > 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.
-SIEHE AUCH:
+
+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/lfun/AddFixedObject b/doc/lfun/AddFixedObject
index 3e2e172..5875ee2 100644
--- a/doc/lfun/AddFixedObject
+++ b/doc/lfun/AddFixedObject
@@ -1,52 +1,74 @@
+
AddFixedObject()
+****************
-FUNKTION:
- varargs void AddFixedObject(string str, int val, mixed ids);
-DEFINIERT IN:
- /std/room/shop.c
+FUNKTION
+========
-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.
+ varargs void AddFixedObject(string str, int val, mixed ids);
-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".
+DEFINIERT IN
+============
-SIEHE AUCH:
- RemoveFixedObject(), SetStorageRoom(), /std/store.c
-
-----------------------------------------------------------------------------
-Letzte Aenderung: Sat Nov 9 12:59:25 2002 durch Bambi
+ /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/lfun/AddFood b/doc/lfun/AddFood
index 2da18e5..b870a5e 100644
--- a/doc/lfun/AddFood
+++ b/doc/lfun/AddFood
@@ -1,12 +1,18 @@
+
AddFood()
+*********
-BEMERKUNGEN:
- Die Funktion AddFood() sollte NICHT MEHR BENUTZT werden.
- Bitte AddToMenu() verwenden.
+BEMERKUNGEN
+===========
-SIEHE AUCH:
- AddToMenu(), RemoveFromMenu()
+ 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/lfun/AddFuel b/doc/lfun/AddFuel
index bf00350..cd0b25e 100644
--- a/doc/lfun/AddFuel
+++ b/doc/lfun/AddFuel
@@ -1,29 +1,51 @@
+
AddFuel()
+*********
-FUNKTION:
- void AddFuel(int fuel);
-DEFINIERT IN:
- /std/lightsource.c
+FUNKTION
+========
-ARGUMENTE:
- fuel
- Die zusaetzliche Brenndauer in Sekunden.
+ void AddFuel(int fuel);
-BESCHREIBUNG:
- Die Brenndauer der Lichtquelle wird um fuel Sekunden verlaengert.
-RUeCKGABEWERT:
- keiner
+DEFINIERT IN
+============
-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.
+ /std/lightsource.c
-SIEHE AUCH:
- /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/lfun/AddFun b/doc/lfun/AddFun
index 925b5ac..5ba6cf1 100644
--- a/doc/lfun/AddFun
+++ b/doc/lfun/AddFun
@@ -1,63 +1,85 @@
+
AddFun()
+********
-FUNKTION:
- void AddFun(string fun, int next);
-DEFINIERT IN:
- /std/transport.c
+FUNKTION
+========
-ARGUMENTE:
- fun
- Name der Funktion.
- next
- Zeit bis zur naechsten Fahrplanstation.
+ void AddFun(string fun, int next);
-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
+DEFINIERT IN
+============
-BEISPIELE:
- Wenn ein zufaellig ausgewaehlter Passagier eines Schiffes unterwegs
- seekrank werden soll, koennte man das wie folgt realisieren:
+ /std/transport.c
- create()
- {
- ...
- AddFun("seekrank", 5);
- ...
- }
+ARGUMENTE
+=========
- seekrank()
- {
- object *passagiere, opfer;
+ fun
+ Name der Funktion.
+ next
+ Zeit bis zur naechsten Fahrplanstation.
- // soll nicht immer passieren
- if (random(5))
- return;
- // Opfer auswaehlen
- passagiere = QueryPassengers();
- if (sizeof(passagiere))
- opfer = passagiere[random(sizeof(passagiere))];
+BESCHREIBUNG
+============
- // 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 }) );
- }
+ 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.
-SIEHE AUCH:
- AddRoute(), AddMsg(), /std/transport.c
-----------------------------------------------------------------------------
+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/lfun/AddId b/doc/lfun/AddId
index fa1ce76..8c2aa4e 100644
--- a/doc/lfun/AddId
+++ b/doc/lfun/AddId
@@ -1,50 +1,75 @@
+
AddId()
+*******
-FUNKTION:
- void AddId(string|string* ids);
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-ARGUMENTE:
- ids
- String oder Array von Strings mit den Bezeichnungen, mit denen
- sich sich das Objekt ansprechen lassen soll.
+ void AddId(string|string* ids);
-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
+DEFINIERT IN
+============
-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.
+ /std/thing/description.c
-BEISPIELE:
- AddId( "buch" );
- AddId( "buechlein" );
+ARGUMENTE
+=========
- Das Objekt laesst sich jetzt als "buch" und als "buechlein" ansprechen.
+ ids
+ String oder Array von Strings mit den Bezeichnungen, mit denen
+ sich sich das Objekt ansprechen lassen soll.
- AddId( ({ "buch", "buechlein" }) );
- Diese Zeile bewirkt das gleiche wie die obigen zwei Zeilen.
+BESCHREIBUNG
+============
- AddId( ({ "puzzle", "\nquest_puzzle" }) );
+ Jedes Objekt sollte sich auf die eine oder andere Weise ansprechen
+ lassen. Zu diesem Zweck kann man dem Objekt mit dieser Funktion
+ Bezeichner uebergeben.
- 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
+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/lfun/AddInfo b/doc/lfun/AddInfo
index 2164584..759a300 100644
--- a/doc/lfun/AddInfo
+++ b/doc/lfun/AddInfo
@@ -1,222 +1,243 @@
+
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();
- ...
+FUNKTION
+========
- // "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);
- ...
+ varargs void AddInfo( frage, meldung
+ [, indent [, [silent [, casebased] ] ] );
- // 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()}));
+DEFINIERT IN
+============
- // 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.":"")):
- ""));
- }
+ /std/npc/info.c
- // "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
+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/lfun/AddItem b/doc/lfun/AddItem
index 8e812ea..222b24d 100644
--- a/doc/lfun/AddItem
+++ b/doc/lfun/AddItem
@@ -1,159 +1,184 @@
+
AddItem()
+*********
-FUNKTION:
- varargs object AddItem(mixed filename,int refresh,mixed props);
-DEFINIERT IN:
- /std/room/items.c
- /std/npc/items.c
+FUNKTION
+========
-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.
+ varargs object AddItem(mixed filename,int refresh,mixed props);
-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!
+DEFINIERT IN
+============
-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!
+ /std/room/items.c
+ /std/npc/items.c
- 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);
+ARGUMENTE
+=========
-SIEHE AUCH:
- RemoveItem(), replace_program(), create(), P_GUARD,
- /std/room/items.c, /std/npc/items.c,
- /sys/rooms.h, /sys/npc.h
+ 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/lfun/AddKnownPotion b/doc/lfun/AddKnownPotion
index 4d4d296..874e55c 100644
--- a/doc/lfun/AddKnownPotion
+++ b/doc/lfun/AddKnownPotion
@@ -1,25 +1,45 @@
+
AddKnownPotion()
+****************
-FUNKTION:
- int AddKnownPotion(int nr)
-DEFINIERT IN:
- /std/player/potion.c
+FUNKTION
+========
-ARGUMENTE:
- int nr Nummer eines ZTs
+ int AddKnownPotion(int nr)
-BESCHREIBUNG:
- Addiert einen ZT als bekannt in einem Spieler. Nur vom Orakel rufbar.
-RUeCKGABEWERT:
- 1 Erfolg
- -1 fehlende Berechtigung
- -2 Nummer bereits eingetragen
+DEFINIERT IN
+============
-SIEHE AUCH:
- Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
- Verwandt: FindPotion(), RemoveKnownPotion(), InList()
- Props: P_POTIONROOMS, P_KNOWN_POTIONROOMS
+ /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/lfun/AddMaterial b/doc/lfun/AddMaterial
index d4f50b7..7f90d82 100644
--- a/doc/lfun/AddMaterial
+++ b/doc/lfun/AddMaterial
@@ -1,76 +1,100 @@
+
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>
+FUNKTION
+========
- int gender
- Geschlecht des einzutragenden Materials
+ private static varargs void AddMaterial(string mat, int gender,
+ mixed names, mixed groups,
+ mixed dif) {
- 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,...])
+DEFINIERT IN
+============
- 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
+ /p/daemon/materialdb.c (MATERIALDB)
-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}));
+ARGUMENTE
+=========
- 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 :) ).
+ string mat
+ Materialstring, definiert in <thing/material.h>
-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
+ int gender
+ Geschlecht des einzutragenden Materials
-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
+ mixed names
+ Name des Materials:
+ - "<Nominativ>" oder (meist nur Nom. und Gen. noetig)
+ - ({"<Nominativ>","<Genitiv>","<Dativ>","<Akkusativ>"})
-7. Mai 2004 Gloinson
\ No newline at end of file
+ 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/lfun/AddMiniQuest b/doc/lfun/AddMiniQuest
index 91e7857..787e718 100644
--- a/doc/lfun/AddMiniQuest
+++ b/doc/lfun/AddMiniQuest
@@ -1,54 +1,71 @@
+
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
+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/lfun/AddMoney b/doc/lfun/AddMoney
index 229d1cc..b9e16b2 100644
--- a/doc/lfun/AddMoney
+++ b/doc/lfun/AddMoney
@@ -1,62 +1,92 @@
+
+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
+FUNKTION
+========
-BESCHREIBUNG:
- Dem Spieler wird die in <amount> festgelegte Geldmenge abgezogen oder
- zugefuehrt.
+ public int AddMoney(int amount);
-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.
+DEFINIERT IN
+============
- 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.
+ /std/container/moneyhandler.c
+ /std/living/moneyhandler.c
+ /std/player/moneyhandler.c
- 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);
+ARGUMENTE
+=========
- // nimm ihm Geld
- if(this_player()->AddMoney(-50)==1)
- write("Der Ork beklaut dich!\n");
+ int amount
+ Die zufuehrende oder abziehende Geldmenge
-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
+
+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/lfun/AddMsg b/doc/lfun/AddMsg
index 974c905..9faad47 100644
--- a/doc/lfun/AddMsg
+++ b/doc/lfun/AddMsg
@@ -1,42 +1,62 @@
+
AddMsg()
+********
-FUNKTION:
- void AddMsg(string msg, int next);
-DEFINIERT IN:
- /std/transport.c
+FUNKTION
+========
-ARGUMENTE:
- msg
- Die auszugebende Meldung.
- next
- Zeit bis zur naechsten Fahrplanstation.
+ void AddMsg(string msg, int next);
-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.
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- keiner
+ /std/transport.c
-BEISPIELE:
- AddMsg("In der Ferne taucht eine kleine Inseln auf.\n", 10);
- AddMsg("Das Schiff steuert einen kleinen Steg an.\n");
- AddRoute(...);
+ARGUMENTE
+=========
- 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.
+ msg
+ Die auszugebende Meldung.
+ next
+ Zeit bis zur naechsten Fahrplanstation.
-SIEHE AUCH:
- AddRoute(), AddFun(), /std/transport.c
-----------------------------------------------------------------------------
+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/lfun/AddPlant b/doc/lfun/AddPlant
index a79bcff..ae2df8b 100644
--- a/doc/lfun/AddPlant
+++ b/doc/lfun/AddPlant
@@ -1,58 +1,84 @@
+
AddPlant()
+**********
-FUNKTION:
- varargs int AddPlant(string filename, [string|string* npcId])
-DEFINIERT IN:
- /std/room/kraeuter.c
+FUNKTION
+========
-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!
+ varargs int AddPlant(string filename, [string|string* npcId])
-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.
+DEFINIERT IN
+============
-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".
+ /std/room/kraeuter.c
-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();
+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/lfun/AddPluralId b/doc/lfun/AddPluralId
index fd37bb2..8d6d249 100644
--- a/doc/lfun/AddPluralId
+++ b/doc/lfun/AddPluralId
@@ -1,27 +1,49 @@
+
AddPluralId()
+*************
-FUNKTION:
- void AddPluralId(mixed id);
-DEFINIERT IN:
- /std/unit.c
+FUNKTION
+========
-ARGUMENTE:
- id
- Identfikationsstring oder Array von Strings
+ void AddPluralId(mixed id);
-BESCHREIBUNG:
- Es werden ein oder mehrere Bezeichner hinzugefuegt, mit denen sich
- mehrere Einheiten der Menge ansprechen lassen.
-RUeCKGABEWERT:
- keiner
+DEFINIERT IN
+============
-BEISPIELE:
- siehe /items/money.c
+ /std/unit.c
-SIEHE AUCH:
- AddSingularId(), RemovePluralId(), AddId(), id(), /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/lfun/AddPursuer b/doc/lfun/AddPursuer
index 451ea9d..f4839e6 100644
--- a/doc/lfun/AddPursuer
+++ b/doc/lfun/AddPursuer
@@ -1,29 +1,52 @@
+
AddPursuer()
+************
-FUNKTION:
- void AddPursuer(object pursuer)
-ARGUMENTE:
- pursuer: Objekt, das demjenigen folgen soll, in dem AddPursuer
- aufgerufen wurde.
+FUNKTION
+========
-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.
+ void AddPursuer(object pursuer)
-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.
+ARGUMENTE
+=========
-BEISPIELE:
- find_player("jof")->AddPursuer(find_player("kirk"))
- Danach wird Jof von Kirk verfolgt.
+ pursuer: Objekt, das demjenigen folgen soll, in dem AddPursuer
+ aufgerufen wurde.
-SIEHE AUCH:
- "RemovePursuer", "PreventFollow"
+
+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/lfun/AddReadDetail b/doc/lfun/AddReadDetail
index c8de775..7f36aa4 100644
--- a/doc/lfun/AddReadDetail
+++ b/doc/lfun/AddReadDetail
@@ -1,80 +1,102 @@
+
AddReadDetail()
+***************
-FUNKTION:
- void AddReadDetail(string|string*keys,
- string|string*|mapping|closure desc);
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-ARGUMENTE:
- keys
- String oder Array von Strings mit den Namen der Details.
- desc
- String, Mapping, String-Array oder Closure mit/zur Beschreibung.
+ void AddReadDetail(string|string*keys,
+ string|string*|mapping|closure desc);
-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.
+DEFINIERT IN
+============
- Fuer lesbare Details koennen Forscherpunkte eingetragen werden.
+ /std/thing/description.c
- 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.
+ARGUMENTE
+=========
- (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.
+ keys
+ String oder Array von Strings mit den Namen der Details.
+ desc
+ String, Mapping, String-Array oder Closure mit/zur Beschreibung.
-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"]));
+BESCHREIBUNG
+============
- AddReadDetail("regeln",
- function string() {
- this_player()->More("/etc/WIZRULES", 1);
- return "";
- });
+ 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", ...]).
-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()
+ 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/lfun/AddResistanceModifier b/doc/lfun/AddResistanceModifier
index 6476f86..b8a5ad8 100644
--- a/doc/lfun/AddResistanceModifier
+++ b/doc/lfun/AddResistanceModifier
@@ -1,49 +1,75 @@
+
AddResistanceModifier()
+***********************
-FUNKTION:
- varargs int AddResistanceModifier(mapping mod, string add)
-DEFINIERT IN:
- /std/living/combat.c
+FUNKTION
+========
-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.
+ varargs int AddResistanceModifier(mapping mod, string add)
-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.
+DEFINIERT IN
+============
-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);
- ...
- }
+ /std/living/combat.c
-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
+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/lfun/AddRoomCmd b/doc/lfun/AddRoomCmd
index 5e206fe..f4aeb68 100644
--- a/doc/lfun/AddRoomCmd
+++ b/doc/lfun/AddRoomCmd
@@ -1,13 +1,23 @@
+
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.
+SYNTAX
+======
-SIEHE AUCH:
- "AddCmd"
+ 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/lfun/AddRoomMessage b/doc/lfun/AddRoomMessage
index 4a9ca12..aa700c1 100644
--- a/doc/lfun/AddRoomMessage
+++ b/doc/lfun/AddRoomMessage
@@ -1,80 +1,103 @@
+
AddRoomMessage()
+****************
-FUNKTION:
- void AddRoomMessage(string *msg, int time, mixed *func);
-DEFINIERT IN:
- /std/room/description.c
+FUNKTION
+========
-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
+ void AddRoomMessage(string *msg, int time, mixed *func);
-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.
+DEFINIERT IN
+============
- 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!
+ /std/room/description.c
-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:
+ARGUMENTE
+=========
- inherit "/std/room";
+ msg
+ Array von Strings mit den Meldungen.
+ time
+ Der Abstand zwischen zwei Meldungen in Sekunden.
+ func (optional)
+ String oder Array von Strings mit Funktionsnamen
- 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" );
- }
+BESCHREIBUNG
+============
- // 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
- }
+ Mit dieser Funktion legt man fest, dass in bestimmten Zeitabstaenden
+ Meldungen an den Raum geschickt werden sollen.
-SIEHE AUCH:
- Verwandt: tell_room(), ReceiveMsg()
- Props: P_ROOM_MSG, P_FUNC_MSG, P_MSG_PROB
+ 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/lfun/AddRoute b/doc/lfun/AddRoute
index 3ca0093..265fa8a 100644
--- a/doc/lfun/AddRoute
+++ b/doc/lfun/AddRoute
@@ -1,84 +1,114 @@
+
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.
+FUNKTION
+========
-BESCHREIBUNG:
- Dem Fahrplan des Transporters wird eine neue Haltestelle hinzugefuegt.
+ public varargs void AddRoute(string room, int stay, int next,
+ string harbour_desc, mixed dest_ids, string deststr)
- 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:
+DEFINIERT IN
+============
- AddRoute("/d/ebene/room/PortVain/po_haf2", 40,
- 10, "Hafen von Port Vain");
+ /std/transport.c
- 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.
+ARGUMENTE
+=========
- 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).
+ 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.
-SIEHE AUCH:
-Funktionen: AddMsg(L), AddFun(L), /std/transport.c
-Properties: P_HARBOUR, P_NO_TRAVELING, P_TRAVEL_INFO
+
+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/lfun/AddSingularId b/doc/lfun/AddSingularId
index d956567..c45199e 100644
--- a/doc/lfun/AddSingularId
+++ b/doc/lfun/AddSingularId
@@ -1,27 +1,49 @@
+
AddSingularId()
+***************
-FUNKTION:
- void AddSingularId(mixed id);
-DEFINIERT IN:
- /std/unit.c
+FUNKTION
+========
-ARGUMENTE:
- id
- Identifikationsstring oder Array von Strings
+ void AddSingularId(mixed id);
-BESCHREIBUNG:
- Es werden ein oder mehrere Bezeichner hinzugefuegt, mit denen sich eine
- einzelne Einheit ansprechen laesst.
-RUeCKGABEWERT:
- keiner
+DEFINIERT IN
+============
-BEISPIELE:
- siehe /items/money.c
+ /std/unit.c
-SIEHE AUCH:
- AddPluralId(), RemoveSingularId(), AddId(), id(), /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/lfun/AddSmells b/doc/lfun/AddSmells
index 5682f00..2623f98 100644
--- a/doc/lfun/AddSmells
+++ b/doc/lfun/AddSmells
@@ -1,71 +1,92 @@
+
AddSmells()
+***********
-FUNKTION:
- void AddSmells(string|string* keys, string|string*|mapping|closure desc);
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-ARGUMENTE:
- keys
- String oder Array von Strings mit den Namen der Details.
- desc
- String, Mapping, String-Array oder Closure mit/zur Beschreibung.
+ void AddSmells(string|string* keys, string|string*|mapping|closure desc);
-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.
+DEFINIERT IN
+============
- Fuer Geruchsdetails koennen Forscherpunkte eingetragen werden.
+ /std/thing/description.c
- 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";
- }
+ARGUMENTE
+=========
-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()
+ 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/lfun/AddSounds b/doc/lfun/AddSounds
index b38389a..b14b976 100644
--- a/doc/lfun/AddSounds
+++ b/doc/lfun/AddSounds
@@ -1,63 +1,82 @@
+
AddSounds()
+***********
-FUNKTION:
- void AddSounds(string|string* keys, string|string*|mapping|closure desc);
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-ARGUMENTE:
- keys
- String oder Array von Strings mit den Namen der Details.
- desc
- String, Mapping, String-Array oder Closure mit/zur Beschreibung.
+ void AddSounds(string|string* keys, string|string*|mapping|closure desc);
-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.
+DEFINIERT IN
+============
- Fuer Geraeuschdetails koennen Forscherpunkte eingetragen werden.
+ /std/thing/description.c
- Gerauesche koennen allgemein einen Raum oder Objekt zugeordnet werden:
- dafuer muss man als <key> SENSE_DEFAULT uebergeben.
- Spielerkommandos: "lausche", "lausch", "hoer", "hoere"
+ARGUMENTE
+=========
-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"]));
+ keys
+ String oder Array von Strings mit den Namen der Details.
+ desc
+ String, Mapping, String-Array oder Closure mit/zur Beschreibung.
-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()
+
+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/lfun/AddSpecialDetail b/doc/lfun/AddSpecialDetail
index 90c5543..3405eec 100644
--- a/doc/lfun/AddSpecialDetail
+++ b/doc/lfun/AddSpecialDetail
@@ -1,61 +1,87 @@
-VERALTET: AddSpecialDetail()
-FUNKTION:
- void AddSpecialDetail(string|string* keys, string func);
+AddSpecialDetail()
+******************
-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.
+VERALTET AddSpecialDetail()
+===========================
-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.
+FUNKTION
+========
-BEISPIELE:
- Ein zustandsabhaengiges Detail:
+ void AddSpecialDetail(string|string* keys, string func);
- 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.
+DEFINIERT IN
+============
-BEMERKUNG:
- Intern werden Details und SpecialDetails im selben Mapping
- verwaltet.
- Man kann statt dieser Funktion deshalb auch AddDetail mit Closures
- nutzen.
+ /std/thing/description.c
-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()
+
+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/lfun/AddSpecialExit b/doc/lfun/AddSpecialExit
index b6b54bb..2f16c17 100644
--- a/doc/lfun/AddSpecialExit
+++ b/doc/lfun/AddSpecialExit
@@ -1,58 +1,82 @@
+
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
+FUNKTION
+========
-BESCHREIBUNG:
- Es wird ein Ausgang in die Richtung(en) cmd eingefuegt. Wird der
- Ausgang benutzt, so wird die Closure bzw. Funktion func ausgefuehrt.
+ void AddSpecialExit(string|string* cmd, string|closure func);
- 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.
+DEFINIERT IN
+============
- func bekommt als Parameter einen String mit der gewaehlten
- Bewegungsrichtung uebergeben.
+ /std/room/exits
-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);
+ARGUMENTE
+=========
- 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");
+ 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
+
+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/lfun/AddSpecialInfo b/doc/lfun/AddSpecialInfo
index 735983f..efc3067 100644
--- a/doc/lfun/AddSpecialInfo
+++ b/doc/lfun/AddSpecialInfo
@@ -1,64 +1,88 @@
+
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
+FUNKTION
+========
-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.
+ varargs void AddSpecialInfo( frage, meldung
+ [, indent [, [silent [, casebased] ] ] );
- Fuer die Beschreibung der weiteren Parameter siehe man AddInfo(L).
- AddSpecialInfo(keys, "function", ...) entspricht:
- - AddInfo(keys, #'function, ...)
+ARGUMENTE
+=========
-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().
+ 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.
-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!
+DEFINIERT IN
+============
-SIEHE AUCH:
- AddInfo(L), RemoveInfo(L)
+ /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/lfun/AddSpell b/doc/lfun/AddSpell
index 3ec1bf8..1661f8c 100644
--- a/doc/lfun/AddSpell
+++ b/doc/lfun/AddSpell
@@ -1,150 +1,173 @@
+
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
+FUNKTION
+========
-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"
+ varargs int AddSpell(int rate, int damage, string TextForEnemy,
+ string TextForOthers, string|string* dam_type,
+ string|closure func, int|mapping spellarg)
-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.
+DEFINIERT IN
+============
- (*) 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.
+ /std/npc/combat.c
- 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.
+ARGUMENTE
+=========
- 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.
+ 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"
- 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.
+BESCHREIBUNG
+============
-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");
+ Ermoeglicht einfache Angriffs-Zaubersprueche fuer NPCs. Das Ausfuehren von
+ Spells verursacht bei dem NPC keine KP-Kosten.
- (Kleiner Feuerball mit 80% Wahrscheinlichkeit, riesiger mit 10%,
- "augen_stechen" mit 8%, "salto_mortalis" mit 2%)
+ 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.
- // 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");
- }
- }
+ (*) 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.
- // 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
- }
+ 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.
- // #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:
+BEMERKUNGEN
+===========
- // 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
+ 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.
- 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]));
+ 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.
- // 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.
+ 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.
-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
+ 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/lfun/AddToMenu b/doc/lfun/AddToMenu
index 7ceacbb..01d46b6 100644
--- a/doc/lfun/AddToMenu
+++ b/doc/lfun/AddToMenu
@@ -1,240 +1,271 @@
+
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
+FUNKTION
+========
-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.
+ varargs string AddToMenu(string menuetext,
+ mixed ids,
+ mapping minfo,
+ mixed rate,
+ mixed msg,
+ mixed refresh,
+ mixed delay,
+ mixed d_msg);
- 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:
+DEFINIERT IN
+============
- 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.
+ /std/pub.c
- 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:
+ARGUMENTE
+=========
- 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.
+ 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.
-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.
+ 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.
-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>
+ [*] Dieser Parameter kann statt eines festen Zahlenwerts mit
+ folgenden Werten gefuellt werden:
- 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) 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.
- 1) Name der Speise (des Getraenks) auf der Karte (bei menue).
+ 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.
- AddToMenu("'Opa's Drachenkeule'",
+ [**] Zur Erzeugung variabler Meldungen koennen folgende Werte
+ eingetragen werden:
- 2) ids mit denen sich bestellen laesst (z.B. "kaufe keule").
+ 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.
- ({"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.
+BESCHREIBUNG
+============
- ([P_HP:63,P_SP:63,P_FOOD:9,P_VALUE:528]),
+ Mit dieser Funktion werden Speisen oder Getraenke in die Karte
+ von Kneipen und Restaurants eingefuegt.
- 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).
+RUECKGABEWERT
+=============
- ({"Du isst die Keule mit einem schlechten Gewissen.",
- "@WER1 isst die Keule mit einem schlechten Gewissen."}),
+ 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.
- 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.
+BEMERKUNGEN
+===========
- 7) Die Zahl ist die Wartezeit in Sekunden, die der Wirt z.B. fuer
- die Zubereitung und Auslieferung an den Spieler braucht.
+ Die aelteren Funktionen 'AddDrink' bzw. 'AddFood' werden zwar mithilfe
+ dieser maechtigeren Funktion aus Gruenden der Abwaertskompatibilitaet
+ simuliert, sollen aber nicht mehr eingesetzt werden.
- 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."}));
+
+ 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))
+ && - 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()
-----------------------------------------------------------------------------
+SIEHE AUCH
+==========
+
+ AddFood(), AddDrink(), /sys/pub.h
+ RemoveFromMenu(), replace_personal()
+
Last modified: Sam, 01. Okt 2011, 23:40 by Arathorn
diff --git a/doc/lfun/AddTouchDetail b/doc/lfun/AddTouchDetail
index 413e3ca..6ca61e8 100644
--- a/doc/lfun/AddTouchDetail
+++ b/doc/lfun/AddTouchDetail
@@ -1,71 +1,90 @@
+
AddTouchDetail()
+****************
-FUNKTION:
- void AddTouchDetail(string|string* keys,
- string|string*|mapping|closure desc);
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-ARGUMENTE:
- keys
- String oder Array von Strings mit den Namen der Details.
- desc
- String, Mapping, String-Array oder Closure mit/zur Beschreibung.
+ void AddTouchDetail(string|string* keys,
+ string|string*|mapping|closure desc);
-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.
+DEFINIERT IN
+============
- Fuer fuehlbare Details koennen Forscherpunkte eingetragen werden.
+ /std/thing/description.c
- Fuehlbare Details koennen allgemein einen Raum oder Objekt zugeordnet
- werden: dafuer muss man als <key> SENSE_DEFAULT uebergeben.
- Spielerkommandos: "taste"
+ARGUMENTE
+=========
-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]));
+ keys
+ String oder Array von Strings mit den Namen der Details.
+ desc
+ String, Mapping, String-Array oder Closure mit/zur Beschreibung.
- 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()
+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/lfun/AllGroups b/doc/lfun/AllGroups
index 8ffbbca..6511189 100644
--- a/doc/lfun/AllGroups
+++ b/doc/lfun/AllGroups
@@ -1,21 +1,36 @@
+
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).
+FUNKTION
+========
-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()
+ string *AllGroups()
-7. Mai 2004 Gloinson
\ No newline at end of file
+
+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/lfun/AllMaterials b/doc/lfun/AllMaterials
index 6230e9b..57d1f6d 100644
--- a/doc/lfun/AllMaterials
+++ b/doc/lfun/AllMaterials
@@ -1,21 +1,36 @@
+
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).
+FUNKTION
+========
-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()
+ string *AllMaterials()
-7. Mai 2004 Gloinson
\ No newline at end of file
+
+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/lfun/AssocMember b/doc/lfun/AssocMember
index 349157b..139a670 100644
--- a/doc/lfun/AssocMember
+++ b/doc/lfun/AssocMember
@@ -1,52 +1,74 @@
AssocMember()
+*************
-FUNKTION:
- int AssocMember(object npc)
+FUNKTION
+========
-DEFINIERT IN:
- /std/living/team.c
+ int AssocMember(object npc)
-ARGUMENTE:
- Der zuzuordnende NPC.
-BESCHREIBUNG:
- Ordnet einen NPC einem Spieler zu. Dieser ist dann
- immer im Team des Spielers, moeglichst in der gleichen Reihe.
+DEFINIERT IN
+============
-RUECKGABEWERT:
- 1, falls Zuordnung erfolgreich, sonst 0.
+ /std/living/team.c
-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.
+ARGUMENTE
+=========
-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
+ 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/lfun/Attack b/doc/lfun/Attack
index 4656ae9..08a0c20 100644
--- a/doc/lfun/Attack
+++ b/doc/lfun/Attack
@@ -1,22 +1,42 @@
+
Attack()
+********
-FUNKTION:
- void Attack(object enemy)
-ARGUMENTE:
- enemy: Der Feind.
+FUNKTION
+========
-BESCHREIBUNG:
- Der Feind wird der Staerke der Waffe (bzw. der Haende) entsprechend
- stark angegriffen.
+ void Attack(object enemy)
-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
+ARGUMENTE
+=========
-SIEHE AUCH:
- "Defend", "QueryDamage"
+ 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/lfun/BecomesNetAlive b/doc/lfun/BecomesNetAlive
index 22a6cdc..a64f328 100644
--- a/doc/lfun/BecomesNetAlive
+++ b/doc/lfun/BecomesNetAlive
@@ -1,46 +1,68 @@
+
BecomesNetAlive()
+*****************
-FUNKTION:
- void BecomesNetAlive(object pl);
-GERUFEN VON:
- /std/player/base.c
+FUNKTION
+========
-ARGUMENTE:
- pl
- Spieler, der Verbindung zum MUD wiedererlangt.
+ void BecomesNetAlive(object pl);
-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.
+GERUFEN VON
+===========
-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.
+ /std/player/base.c
-SIEHE AUCH:
- BecomesNetDead(), PlayerQuit(), /std/player/base.c, /room/netztot.c
-24. Aug 2011 Gloinson
\ No newline at end of file
+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/lfun/BecomesNetDead b/doc/lfun/BecomesNetDead
index fcfed7c..8938d13 100644
--- a/doc/lfun/BecomesNetDead
+++ b/doc/lfun/BecomesNetDead
@@ -1,45 +1,67 @@
+
BecomesNetDead()
+****************
-FUNKTION:
- void BecomesNetDead(object pl);
-GERUFEN VON:
- /std/player/base.c
+FUNKTION
+========
-ARGUMENTE:
- object pl
- Spieler, der Verbindung zum MUD verliert.
+ void BecomesNetDead(object pl);
-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.
+GERUFEN VON
+===========
-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.
+ /std/player/base.c
-SIEHE AUCH:
- BecomesNetAlive(), PlayerQuit(), /std/player/base.c, /room/netztot.c
-24. Aug 2011, Gloinson
\ No newline at end of file
+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/lfun/CannotSee b/doc/lfun/CannotSee
index 3869541..b86d33a 100644
--- a/doc/lfun/CannotSee
+++ b/doc/lfun/CannotSee
@@ -1,30 +1,49 @@
+
CannotSee()
+***********
-FUNKTION:
- varargs int CannotSee(int silent);
-DEFINIERT IN:
- /std/living/light.c
+FUNKTION
+========
-ARGUMENTE:
- silent - Soll an das Lebewesen direkt automatisch eine Meldung
- ausgegeben werden wenn es nichts sehen kann?
+ varargs int CannotSee(int silent);
-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
+DEFINIERT IN
+============
-SIEHE AUCH:
- P_BLIND, P_LIGHT_MODIFIER, P_PLAYER_LIGHT
+ /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/lfun/ChangeMiniQuest b/doc/lfun/ChangeMiniQuest
index a6bfb7d..507bd68 100644
--- a/doc/lfun/ChangeMiniQuest
+++ b/doc/lfun/ChangeMiniQuest
@@ -1,48 +1,72 @@
-FUNKTION:
- int ChangeMiniQuest(mixed questgeber, int parameter, mixed newvalue)
-DEFINIERT IN:
- /secure/questmaster
+ChangeMiniQuest()
+*****************
-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
+FUNKTION
+========
-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.
+ int ChangeMiniQuest(mixed questgeber, int parameter, mixed newvalue)
-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:
+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/lfun/ChangeReputation b/doc/lfun/ChangeReputation
index e7c3af6..c3d010e 100644
--- a/doc/lfun/ChangeReputation
+++ b/doc/lfun/ChangeReputation
@@ -1,45 +1,72 @@
-ChangeReputation
-FUNKTION:
- public varargs int ChangeReputation(string repid, int value, int silent)
-DEFINIERT IN:
- /std/player/reputation.c
+ChangeReputation()
+******************
-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.
+FUNKTION
+========
-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
+ public varargs int ChangeReputation(string repid, int value, int silent)
-BEISPIELE:
- s. reputation
-SIEHE AUCH:
- reputation
- GetReputation(), GetReputations()
+DEFINIERT IN
+============
-ZULETZT GEAeNDERT:
+ /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/lfun/CheckFindRestrictions b/doc/lfun/CheckFindRestrictions
index f9c96e5..a021a58 100644
--- a/doc/lfun/CheckFindRestrictions
+++ b/doc/lfun/CheckFindRestrictions
@@ -1,23 +1,43 @@
-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)
+CheckFindRestrictions()
+***********************
-BESCHREIBUNG:
- Funktion, die FindBestWeapon / FindBestArmours einschraenkt.
- Wird in Wert ungleich 0 zurueckgeliefert, so wird das Objekt
- nicht genommen.
-RUECKGABEWERT:
- Normalerweise 0
+FUNKTION
+========
-SIEHE AUCH:
- FindBestWeapon(), FindBestArmours()
+ 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/lfun/CheckLightType b/doc/lfun/CheckLightType
index 1a0490a..2296ab8 100644
--- a/doc/lfun/CheckLightType
+++ b/doc/lfun/CheckLightType
@@ -1,84 +1,110 @@
+
CheckLightType()
+****************
-FUNKTION:
- varargs int CheckLightType(int lighttype, int mode);
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-ARGUMENTE:
- lighttype
- Auf diesen Lichttyp wird getestet.
- mode
- Die Methode, nach der der Lichttyp ueberprueft wird.
+ varargs int CheckLightType(int lighttype, int mode);
-BESCHREIBUNG:
- Die Funktion prueft, ob der uebergebene lighttype mit dem in
- P_LIGHT_TYPE definierten Lichttyp uebereinstimmt.
- Dabei kann in verschiedenen Modi getestet werden:
+DEFINIERT IN
+============
- 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.
+ /std/thing/description.c
- 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.
+ARGUMENTE
+=========
- LT_CHECK_NONE
- Es wird geprueft, ob keiner der uebergebenen Lichttypen vorhanden
- sind. Ob sonst noch andere Lichttypen vorhanden sind, ist dabei
- egal.
+ lighttype
+ Auf diesen Lichttyp wird getestet.
+ mode
+ Die Methode, nach der der Lichttyp ueberprueft wird.
-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):
+BESCHREIBUNG
+============
- raum->SetProp( P_LIGHT_TYPE, LT_SUN|LT_OPEN_FIRE|LT_GLOWING );
+ Die Funktion prueft, ob der uebergebene lighttype mit dem in
+ P_LIGHT_TYPE definierten Lichttyp uebereinstimmt.
- Es soll getestet werden, ob an in dem Raum Tageslicht herrscht:
+ Dabei kann in verschiedenen Modi getestet werden:
- raum->CheckLightType(LT_DAYLIGHT, LT_CHECK_ANY);
- raum->CheckLightType(LT_DAYLIGHT); // gleichwertig
+ 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.
- Die Funktion ergibt wahr, da LT_DAYLIGHT unter anderem LT_SUN ent-
- haelt (vgl man P_LIGHT_TYPES).
+ LT_CHECK_ALL
+ Es wird geprueft, ob alle in lighttype definierten Lichttypen
+ vorhanden sind. Es koennen aber auch mehr Lichttypen definiert
+ sein.
- Es soll getestet werden, dass weder Mond noch Sterne im Raum sind:
+ 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.
- raum->CheckLightType(LT_MOON|LT_STARS, LT_CHECK_NONE);
+ LT_CHECK_NONE
+ Es wird geprueft, ob keiner der uebergebenen Lichttypen vorhanden
+ sind. Ob sonst noch andere Lichttypen vorhanden sind, ist dabei
+ egal.
- Die Funktion ergibt wahr, da die beiden nicht gesetzt sind.
- Es soll geprueft werden, ob Mond und Sterne im Raum leuchten:
+RUeCKGABEWERT
+=============
- raum->CheckLightType(LT_MOON|LT_STARS, LT_CHECK_ALL);
+ 0 wenn die geprueften Bedingungen nicht korrekt sind, sonst
+ ein Wert ungleich 0.
- 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.
+BEISPIELE
+=========
-SIEHE AUCH:
- /std/thing/description.c, /std/thing/lighttypes.h, P_LIGHT_TYPE
-----------------------------------------------------------------------------
+ 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/lfun/CheckResistance b/doc/lfun/CheckResistance
index 45486a5..bcf64ca 100644
--- a/doc/lfun/CheckResistance
+++ b/doc/lfun/CheckResistance
@@ -1,20 +1,37 @@
+
CheckResistance()
+*****************
-FUNKTION:
- CheckRessistance(string* dam_type_list)
-ARGUMENTE:
- dam_type_list: Liste der Schadensarten, die geprueft werden
+FUNKTION
+========
-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.
+ CheckRessistance(string* dam_type_list)
-RUECKGABEWERT:
- Ein Faktor, der mit dem Schaden multipliziert wird, vom Typ "float".
-SIEHE AUCH:
- "Defend"
+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/lfun/CheckSensitiveAttack b/doc/lfun/CheckSensitiveAttack
index 32aec2e..74f6220 100644
--- a/doc/lfun/CheckSensitiveAttack
+++ b/doc/lfun/CheckSensitiveAttack
@@ -1,33 +1,54 @@
+
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
+FUNKTION
+========
-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.
+ void CheckSensitiveAttack(int dam, string *dam_type, mixed spell,
+ object enemy)
-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
+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/lfun/CheckSpellFatigue b/doc/lfun/CheckSpellFatigue
index 0d7cc2a..ac9d3fe 100644
--- a/doc/lfun/CheckSpellFatigue
+++ b/doc/lfun/CheckSpellFatigue
@@ -1,61 +1,85 @@
-CheckSpellFatigue
-FUNKTION:
- public varargs int CheckSpellFatigue(string key)
+CheckSpellFatigue()
+*******************
-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.
+FUNKTION
+========
-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.
+ public varargs int CheckSpellFatigue(string key)
- 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.
+DEFINIERT IN
+============
- >0 Spruchermuedung ist noch nicht abgelaufen, Rueckgabewert ist die
- Zeit, bei der dieser Eintrag ablaeuft. Der Spruch darf _nicht_
- ausgefuehrt werden.
+ /std/living/skills.c
+ /std/player/skills.c
+ /sys/living/skills.h
-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.
+ARGUMENTE
+=========
-SIEHE AUCH:
- SetSpellFatigue(L), DeleteSpellFatigue(L)
- P_NEXT_SPELL_TIME
- spruchermuedung
+ 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/lfun/ClearRingBuffer b/doc/lfun/ClearRingBuffer
index 0095dec..869d298 100644
--- a/doc/lfun/ClearRingBuffer
+++ b/doc/lfun/ClearRingBuffer
@@ -1,34 +1,56 @@
+
ClearRingBuffer()
+*****************
-FUNKTION:
- protected struct std_ringbuffer ClearRingBuffer(struct std_ringbuffer b);
-DEFINIERT IN:
- /std/util/ringbuffer.c
- /sys/util/ringbuffer.h
+FUNKTION
+========
-ARGUMENTE:
- b - der zu loeschende Ringpuffer
+ protected struct std_ringbuffer ClearRingBuffer(struct std_ringbuffer b);
-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);
+DEFINIERT IN
+============
-SIEHE AUCH:
- CreateRingBuffer(), RingBufferGet(), ResizeRingBuffer()
+ /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/lfun/Configure b/doc/lfun/Configure
index 9763999..5a919ce 100644
--- a/doc/lfun/Configure
+++ b/doc/lfun/Configure
@@ -1,23 +1,38 @@
+
+Configure()
+***********
+
Configure()
- public mixed Configure(mixed data)
+ public mixed Configure(mixed data)
-DEFINIERT IN:
+
+DEFINIERT IN
+============
+
Beliebigen Objekten
-ARGUMENTE:
+
+ARGUMENTE
+=========
+
<data>
0 fuer Datenabfrage
beliebige Daten, die ein Configure(0) vorher lieferte
-BESCHREIBUNG:
+
+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
@@ -29,7 +44,10 @@
von Configure(data) wieder gesetzt. Das Configure MUSS genau die Daten, die
es im alten Objekt zurueckliefert, wieder akzeptieren.
-RUeCKGABEWERT:
+
+RUeCKGABEWERT
+=============
+
Wenn <data>==0:
Alle individuellen Daten in einer beliebigen Form. Ein Mapping bietet
sich jedoch an.
@@ -39,13 +57,19 @@
1, wenn die Daten zur Konfiguration akzeptiert wurden.
0, sonst.
-BEMERKUNGEN:
+
+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:
+
+BEISPIELE
+=========
+
Ein Objekt, welches ein anderes Objekt sicher ersetzt, d.h. die
individuelle Konfiguration bleibt erhalten:
mixed data;
@@ -71,6 +95,8 @@
"Daten enthaelt.",78));
}
-LETZTE AeNDERUNG:
-26.09.2011, Zesstra
+LETZTE AeNDERUNG
+================
+
+26.09.2011, Zesstra
diff --git a/doc/lfun/ConvMaterialList b/doc/lfun/ConvMaterialList
index ab4618a..874753b 100644
--- a/doc/lfun/ConvMaterialList
+++ b/doc/lfun/ConvMaterialList
@@ -1,41 +1,65 @@
+
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")
+FUNKTION
+========
-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.
+ varargs string ConvMaterialList(mixed mats, int casus, mixed idinf)
-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.
+DEFINIERT IN
+============
-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
+ /p/daemon/materialdb.c (MATERIALDB)
-7. Mai 2004 Gloinson
\ No newline at end of file
+
+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/lfun/CreateRingBuffer b/doc/lfun/CreateRingBuffer
index 0471af6..e10b671 100644
--- a/doc/lfun/CreateRingBuffer
+++ b/doc/lfun/CreateRingBuffer
@@ -1,45 +1,70 @@
+
CreateRingBuffer()
+******************
-FUNKTION:
- protected struct std_ringbuffer CreateRingBuffer(int size, int newmode);
-DEFINIERT IN:
- /std/util/ringbuffer.c
- /sys/util/ringbuffer.h
+FUNKTION
+========
-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
+ protected struct std_ringbuffer CreateRingBuffer(int size, int newmode);
-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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Der gelieferte Ringpuffer sollte nicht per Hand verarbeitet oder
- genaendert werden, sondern nur ueber die Verwaltungsfunktionen aus
- /std/util/ringbuffer.c.
+ /std/util/ringbuffer.c
+ /sys/util/ringbuffer.h
-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()
+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/lfun/CustomizeObject b/doc/lfun/CustomizeObject
index 4b35092..2c7736a 100644
--- a/doc/lfun/CustomizeObject
+++ b/doc/lfun/CustomizeObject
@@ -1,19 +1,36 @@
-CustomizeObject()
-FUNKTION:
+CustomizeObject()
+*****************
+
+
+FUNKTION
+========
+
string CustomizeObject();
-DEFINIERT IN:
+
+DEFINIERT IN
+============
+
/std/virtual/v_compiler.c
-ARGUMENTE:
+
+ARGUMENTE
+=========
+
keine
-RUeCKGABEWERT:
+
+RUeCKGABEWERT
+=============
+
Den Objektnamen, den das zuletzt erzeugte Objekt (welches gerade die
Funktion aufruft) spaeter vom Driver bekommen wird.
-BESCHREIBUNG:
+
+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.
@@ -24,29 +41,44 @@
Da das VC-Objekt vom VC geclont wurde, ist previous_object() im create()
des VC-Objektes der VC, in dem man CustomizeObject() ruft.
-BEMERKUNGEN:
+
+BEMERKUNGEN
+===========
+
Das CustomizeObject() im Standard-VC gibt nur den zukuenftigen Objektnamen
zurueck und macht sonst nix.
-BEISPIELE:
+
+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...
+ // Kram konfigurier, ja nach myname...
}
-
+
+
+
...
}
-SIEHE AUCH:
- virtual_compiler
- CustomizeObject(), Validate(), NoParaObjects(),
- P_COMPILER_PATH, P_PARA
- /std/virtual/v_compiler.c
-----------------------------------------------------------------------------
+
+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/lfun/Damage b/doc/lfun/Damage
index 3258531..b36061b 100644
--- a/doc/lfun/Damage
+++ b/doc/lfun/Damage
@@ -1,34 +1,56 @@
+
Damage()
+********
-FUNKTION:
- int Damage(int dam);
-DEFINIERT IN:
- /std/armour/combat.c und
- /std/weapon/combat.c
+FUNKTION
+========
-ARGUMENTE:
- dam Der Wert, mit dem die Waffe/Ruestung beschaedig werden soll.
+ int Damage(int dam);
-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.
+DEFINIERT IN
+============
-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.
+ /std/armour/combat.c und
+ /std/weapon/combat.c
-SIEHE AUCH:
- /std/armour/combat.c, /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/lfun/DeAssocMember b/doc/lfun/DeAssocMember
index 5f35326..f47d548 100644
--- a/doc/lfun/DeAssocMember
+++ b/doc/lfun/DeAssocMember
@@ -1,48 +1,71 @@
DeAssocMember()
+***************
-FUNKTION:
- int DeAssocMember(object npc)
+FUNKTION
+========
-DEFINIERT IN:
- /std/living/team.c
+ int DeAssocMember(object npc)
-ARGUMENTE:
- Der NPC, der nicht mehr zugeordnet sein soll.
-BESCHREIBUNG:
- Hebt die Zuordnung eines NPCs zu einem Spieler auf.
+DEFINIERT IN
+============
-RUECKGABEWERT:
- 1, falls Aufhebung erfolgreich, sonst 0.
+ /std/living/team.c
-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.
+ARGUMENTE
+=========
-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
+ 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/lfun/DeclAdj b/doc/lfun/DeclAdj
index f6e4244..d7a7f91 100644
--- a/doc/lfun/DeclAdj
+++ b/doc/lfun/DeclAdj
@@ -1,46 +1,68 @@
+
DeclAdj()
+*********
-FUNKTION:
- varargs string DeclAdj( string adj, int casus, int demon);
-DEFINIERT IN:
- /std/thing/language.c
+FUNKTION
+========
-ARGUMENTE:
- adj
- Das zu deklinierende Adjektiv.
+ varargs string DeclAdj( string adj, int casus, int demon);
- casus
- Der Fall, in den es dekliniert werden soll.
- demon
- Bezieht sich das Adjektiv auf einen bestimmten oder einen
- unbestimmten Gegenstand?
+DEFINIERT IN
+============
-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.
+ /std/thing/language.c
-RUeCKGABEWERT:
- Das deklinierte Adjektiv. Es wird zusaetzlich noch ein Leerzeichen
- hinten angefuegt!
-BEISPIELE:
- Zunaechst ein bestimmtes Adjektiv:
+ARGUMENTE
+=========
- printf("Der %sBall.\n", ball->DeclAdj("gruen", WER, 1);
+ adj
+ Das zu deklinierende Adjektiv.
- Nun ein unbestimmtes Adjektiv:
+ casus
+ Der Fall, in den es dekliniert werden soll.
- printf("Ein %sBall.\n", ball->DeclAdj("gruen", WER, 0);
+ demon
+ Bezieht sich das Adjektiv auf einen bestimmten oder einen
+ unbestimmten Gegenstand?
- Da DeclAdj() "gruene " bzw. "gruener " zurueckgibt, darf zwischen dem
- "%s" und dem "Ball" kein Leerzeichen stehen!
-SIEHE AUCH:
- /std/thing/language.c
+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/lfun/Defend b/doc/lfun/Defend
index e02264a..aa53945 100644
--- a/doc/lfun/Defend
+++ b/doc/lfun/Defend
@@ -1,150 +1,175 @@
+
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
+FUNKTION
+========
-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.
+ public int Defend(int dam, string|string* dam_type, int|mapping spell,
+ object enemy)
- 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.
+DEFINIERT IN
+============
- Ist ein Treffer x LP hart, werden die Meldungen des lphit-
- Arrays ausgegeben, dessen Wert am naehesten unter dem Schaden
- liegt.
+ /std/living/combat
- 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()
+ARGUMENTE
+=========
-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.
+ 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
- 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.
+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 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 (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());
+ // ein magischer Angriff mit Treffermeldung: enem->Defend(100,
+ ({DT_BLUDGEON, DT_FIRE}), ([SP_SHOW_DAMAGE:1]),
-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
+ 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/lfun/DefendFunc b/doc/lfun/DefendFunc
index 7043e04..1683b3f 100644
--- a/doc/lfun/DefendFunc
+++ b/doc/lfun/DefendFunc
@@ -1,78 +1,107 @@
+
+DefendFunc()
+************
+
+
DefendFunc(L)
+=============
-FUNKTION:
- int DefendFunc(string|string *dtyp, int|mappingspell, object enemy);
-DEFINIERT IN:
- eigenen Objekten; fuer /std/armour/combat.c
+FUNKTION
+========
-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
+ int DefendFunc(string|string *dtyp, int|mappingspell, object enemy);
-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.
+DEFINIERT IN
+============
-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.
+ eigenen Objekten; fuer /std/armour/combat.c
- 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:
+ARGUMENTE
+=========
- void create()
- {
- ::create();
+ 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
- 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;
+BESCHREIBUNG
+============
- // 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
+ 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.
- // 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;
- }
+RUeCKGABEWERT
+=============
-SIEHE AUCH:
- P_DEFEND_FUNC, QueryDefend(), /std/armour/combat.c
+ 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/lfun/DefendInfo b/doc/lfun/DefendInfo
index 460352a..21d41ac 100644
--- a/doc/lfun/DefendInfo
+++ b/doc/lfun/DefendInfo
@@ -1,168 +1,216 @@
-DefendInfo
-FUNKTION:
-DEFINIERT IN:
- /sys/combat.h
+DefendInfo()
+************
-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
+FUNKTION
+========
- 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
+DEFINIERT IN
+============
- 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]
+ /sys/combat.h
- DEFEND_GUILD - Array
- Eine Liste mit der Modifikation der Gilde mit der Struktur
- ({
- GUILD_DAM - int
+
+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
- GUILD_DAMTYPE - string/string*
+ HOOK_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
+ 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/lfun/DefendOther b/doc/lfun/DefendOther
index a0b2277..f0386f2 100644
--- a/doc/lfun/DefendOther
+++ b/doc/lfun/DefendOther
@@ -1,85 +1,107 @@
+
DefendOther()
+*************
-FUNKTION:
- mixed DefendOther(int dam,mixed dam_type,mixed spell,object enemy);
-DEFINIERT IN:
- /std/living/combat.c
+FUNKTION
+========
-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.
+ mixed DefendOther(int dam,mixed dam_type,mixed spell,object enemy);
-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.
+DEFINIERT IN
+============
-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.
+ /std/living/combat.c
-SIEHE AUCH:
- AddDefender(), RemoveDefender(), InformDefend(), Kill(), IsEnemy(),
- P_DEFENDERS, /std/living/combat.c, /sys/new_skills.h
-----------------------------------------------------------------------------
+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/lfun/Defend_bsp b/doc/lfun/Defend_bsp
index 06458a5..9feb25f 100644
--- a/doc/lfun/Defend_bsp
+++ b/doc/lfun/Defend_bsp
@@ -1,137 +1,155 @@
+
+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.
+FUNKTION
+========
-BEISPIELE:
- 1) Ein ordinaerer Biss ins Bein.
- this_player()->Defend(random(500),
- ({DT_PIERCE, DT_RIP}),
- 0,
- this_object());
+ varargs int Defend(int dam, mixed dam_type, mixed spell, object enemy)
- 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());
+BEMERKUNGEN
+===========
- 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());
+ Die hier aufgefuehrten Komplexbeispiele sind zum Verstaendnis gedacht.
- // 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)
+BEISPIELE
+=========
- 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());
+ 1) Ein ordinaerer Biss ins Bein.
+ this_player()->Defend(random(500),
+ ({DT_PIERCE, DT_RIP}),
+ 0,
+ 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));
+ 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());
- return 0; // -> In diesem Fall gibts keinen Ruestungsbonus!
- }
+ 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());
- 6b)
- // Eine NUR REINE Luftangriffe reflektierende Ruestung:
- int DefendFunc(string *dtyp, mixed spell, object enemy) {
- if(!sizeof(dtyp-({DT_AIR})) && !spell[SP_RECURSIVE])
- ...
+ 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());
-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)
+ // 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/lfun/DeleteSpellFatigue b/doc/lfun/DeleteSpellFatigue
index c0049d9..f01755b 100644
--- a/doc/lfun/DeleteSpellFatigue
+++ b/doc/lfun/DeleteSpellFatigue
@@ -1,37 +1,55 @@
-DeleteSpellFatigue
-FUNKTION:
- public void DeleteSpellFatigue(string key)
+DeleteSpellFatigue()
+********************
-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.
+FUNKTION
+========
-BESCHREIBUNG:
- Diese Funktion dient zum Loeschen von individuellen Spruchermuedungen
- (Spellfatigue, Spruchsperren).
+ public void DeleteSpellFatigue(string key)
- 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!
+DEFINIERT IN
+============
-SIEHE AUCH:
- SetSpellFatigue(L), CheckSpellFatigue(L)
- P_NEXT_SPELL_TIME
- spruchermuedung
+ /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/lfun/DeleteTimedAttrModifier b/doc/lfun/DeleteTimedAttrModifier
index 069aa90..2d1bd1e 100644
--- a/doc/lfun/DeleteTimedAttrModifier
+++ b/doc/lfun/DeleteTimedAttrModifier
@@ -1,30 +1,53 @@
+
DeleteTimedAttrModifier()
-FUNKTION:
- int DeleteTimedAttrModifier(string key)
+*************************
-DEFINIERT IN:
- /std/living/attributes.c
-ARGUMENTE:
- key - aus P_TIMED_ATTR_MOD zu loeschender Eintrag
+FUNKTION
+========
-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
+ 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/lfun/DiscoverDoor b/doc/lfun/DiscoverDoor
index 88310d5..9046a0e 100644
--- a/doc/lfun/DiscoverDoor
+++ b/doc/lfun/DiscoverDoor
@@ -1,31 +1,54 @@
+
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.
+FUNKTION
+========
-BESCHREIBUNG:
- Nachdem diese Funktion aufgerufen wurde, kann der Seher (this_player())
- das Tor in dem angegebenen Raum immer verwenden.
+ varargs int DiscoverDoor(string dname)
-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.
+ARGUMENTE
+=========
-BEISPIELE:
- write("Der Zauberer sagt: Im Nichts wirst Du ein weiteres Tor finden!\n");
- "/d/seher/portale/sehertormaster"->DiscoverDoor("/room/void");
+ dname: Name des Raumes, in dem der Seher das Sehertor kennenlernen soll.
+ Default: Die Umgebung des Sehers.
-SIEHE AUCH:
- DoorIsKnown, ShowDoors, Teleport, GetDoorsMapping
+
+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/lfun/DistributeExp b/doc/lfun/DistributeExp
index 294eebe..e29427d 100644
--- a/doc/lfun/DistributeExp
+++ b/doc/lfun/DistributeExp
@@ -1,24 +1,42 @@
-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
+
+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/lfun/DoDecay b/doc/lfun/DoDecay
index 85cf541..695856a 100644
--- a/doc/lfun/DoDecay
+++ b/doc/lfun/DoDecay
@@ -1,44 +1,69 @@
+
DoDecay()
+*********
-FUNKTION:
- public int DoDecay(int silent)
-DEFINIERT IN:
- /std/unit.c
+FUNKTION
+========
-ARGUMENTE:
- silent (int)
- Falls != 0, erfolgt beim Zerfall keine Meldung, d.h. doDecayMessaage()
- wird nicht gerufen.
+ public int DoDecay(int silent)
-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*)
+DEFINIERT IN
+============
-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.
+ /std/unit.c
-SIEHE AUCH:
- unit
- P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_FLAGS, P_UNIT_DECAY_QUOTA,
- P_UNIT_DECAY_MIN
- DoDecayMessage()
- /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/lfun/DoDecayMessage b/doc/lfun/DoDecayMessage
index fc39309..671f9c7 100644
--- a/doc/lfun/DoDecayMessage
+++ b/doc/lfun/DoDecayMessage
@@ -1,34 +1,54 @@
+
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
+FUNKTION
+========
-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.
+ protected void DoDecayMessage(int oldamount, int zerfall);
-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
+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/lfun/DoUnwear b/doc/lfun/DoUnwear
index 638eda7..56e53d3 100644
--- a/doc/lfun/DoUnwear
+++ b/doc/lfun/DoUnwear
@@ -1,33 +1,55 @@
+
DoUnwear()
+**********
-FUNKTION:
- varargs int DoUnwear(int silent, int all);
-DEFINIERT IN:
- /std/clothing/wear.c
+FUNKTION
+========
-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.
+ varargs int DoUnwear(int silent, int all);
-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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Auch wenn eine 1 zurueckgegeben wird, muss das nicht heissen, dass die
- Ruestung erfolgreich ausgezogen wurde!
+ /std/clothing/wear.c
-SIEHE AUCH:
- DoWear(), RemoveFunc(), InformUnwear(), /std/armour/combat.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/lfun/DoUnwield b/doc/lfun/DoUnwield
index f33e5f0..d003bfc 100644
--- a/doc/lfun/DoUnwield
+++ b/doc/lfun/DoUnwield
@@ -1,32 +1,54 @@
+
DoUnwield()
+***********
-FUNKTION:
- varargs int DoUnwield(int silent);
-DEFINIERT IN:
- /std/weapon/combat.c
+FUNKTION
+========
-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.
+ varargs int DoUnwield(int silent);
-BESCHREIBUNG:
- Es wird versucht, die Waffe wegzustecken.
-RUeCKGABEWERT:
- 0, wenn die Waffe gar nicht gezueckt war, ansonsten 1.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Anhand des Rueckgabewertes laesst sich nicht ersehen, ob die Waffe sich
- wegstecken liess oder nicht!
+ /std/weapon/combat.c
- Wenn die Waffe verflucht ist oder (falls definiert) UnwieldFunc() 0
- zurueckgibt, laesst sie sich nicht wegstecken.
-SIEHE AUCH:
- UnwieldFunc(), InformUnwield(), /std/weapon.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/lfun/DoWear b/doc/lfun/DoWear
index 0d64e5a..e253290 100644
--- a/doc/lfun/DoWear
+++ b/doc/lfun/DoWear
@@ -1,42 +1,64 @@
+
DoWear()
+********
-FUNKTION:
- varargs int DoWear(int silent, int all);
-DEFINIERT IN:
- /std/armour/combat.c
+FUNKTION
+========
-ARGUMENTE:
- silent
- Falls ungleich 0, so werden keine Meldungen ausgegeben.
- all
- Ungleich 0, wenn DoWear() aus einem "ziehe alles an" heraus
- aufgerufen wurde.
+ varargs int DoWear(int silent, int all);
-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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Auch wenn eine 1 zurueckgegeben wird, muss das nicht heissen, dass die
- Ruestung erfolgreich angezogen wurde!
+ /std/armour/combat.c
- 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
+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/lfun/DoWield b/doc/lfun/DoWield
index 9fc436d..6e6c06c 100644
--- a/doc/lfun/DoWield
+++ b/doc/lfun/DoWield
@@ -1,41 +1,63 @@
+
DoWield()
+*********
-FUNKTION:
- varargs int DoWield(int silent);
-DEFINIERT IN:
- /std/weapon/combat.c
+FUNKTION
+========
-ARGUMENTE:
- silent
- Ungleich 0, wenn die Waffe ohne Meldungen gezueckt werden soll.
+ varargs int DoWield(int silent);
-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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Anhand des Rueckgabewertes laesst sich nicht entscheiden, ob die Waffe
- sich erfolgreich zuecken liess!
+ /std/weapon/combat.c
- 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
+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/lfun/DoorIsKnown b/doc/lfun/DoorIsKnown
index b909e30..b799698 100644
--- a/doc/lfun/DoorIsKnown
+++ b/doc/lfun/DoorIsKnown
@@ -1,24 +1,46 @@
+
DoorIsKnown()
+*************
-FUNKTION:
- int DoorIsKnown()
-ARGUMENTE:
- Keine.
+FUNKTION
+========
-BESCHREIBUNG:
- Testet, ob der Seher (this_player()) das Tor in seiner momentanen
- Umgebung schon kennt.
+ int DoorIsKnown()
-RUECKGABEWERT:
- Die Nummer des Tores.
-BEMERKUNGEN:
- Diese Funktion wird von /d/seher/portale/sehertormaster definiert.
+ARGUMENTE
+=========
-BEISPIELE:
- /d/seher/portale/sehertormaster->DoorIsKnown()
+ Keine.
-SIEHE AUCH:
- DiscoverDoor, ShowDoors, Teleport, GetDoorsMapping
+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/lfun/Dump b/doc/lfun/Dump
index 274fbb4..9d8d7e0 100644
--- a/doc/lfun/Dump
+++ b/doc/lfun/Dump
@@ -1,23 +1,38 @@
+
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.
+FUNKTION
+========
-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()
+ void Dump()
-7. Mai 2004 Gloinson
\ No newline at end of file
+
+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/lfun/EnemyPresent b/doc/lfun/EnemyPresent
index 365ae3d..bf3853c 100644
--- a/doc/lfun/EnemyPresent
+++ b/doc/lfun/EnemyPresent
@@ -1,19 +1,34 @@
-EnemyPresent
-FUNKTION:
- public mixed EnemyPresent()
-DEFINIERT IN:
- /std/living/combat.c
+EnemyPresent()
+**************
-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.
+FUNKTION
+========
-SIEHE AUCH:
- PresentEnemies(), Infight()
+ 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/lfun/Enter b/doc/lfun/Enter
index 7987efa..0ebc7f0 100644
--- a/doc/lfun/Enter
+++ b/doc/lfun/Enter
@@ -1,40 +1,64 @@
+
Enter()
+*******
-FUNKTION:
- int Enter();
-DEFINIERT IN:
- /std/transport.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ int Enter();
-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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Es werden keine Tests durchgefuehrt, ob der Transporter ueberhaupt
- angesprochen wurde! Das muss man selber machen.
+ /std/transport.c
-BEISPIELE:
- int myEnter(string str)
- {
- if (str && id(str))
- return Enter();
+ARGUMENTE
+=========
- notify_fail("Was willst Du betreten?\n");
- return 0;
- }
+ keine
-SIEHE AUCH:
- Leave(), /std/transport.c
-----------------------------------------------------------------------------
+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/lfun/EvalArmour b/doc/lfun/EvalArmour
index f1d356a..7daf07c 100644
--- a/doc/lfun/EvalArmour
+++ b/doc/lfun/EvalArmour
@@ -1,21 +1,40 @@
+
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()
+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/lfun/EvalWeapon b/doc/lfun/EvalWeapon
index 1e671a3..395a0a1 100644
--- a/doc/lfun/EvalWeapon
+++ b/doc/lfun/EvalWeapon
@@ -1,21 +1,40 @@
+
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()
+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/lfun/ExtraAttack b/doc/lfun/ExtraAttack
index 016b5c1..cc0b109 100644
--- a/doc/lfun/ExtraAttack
+++ b/doc/lfun/ExtraAttack
@@ -1,30 +1,49 @@
+
ExtraAttack()
+*************
-FUNKTION:
- varargs public void ExtraAttack(object enemy, int ignore_previous);
-ARGUMENTE:
- enemy: Der Feind.
- ignore_previous: Ein Flag
+FUNKTION
+========
-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.
+ varargs public void ExtraAttack(object enemy, int ignore_previous);
-RUECKGABEWERT:
- Keiner.
-BEMERKUNG:
- Der Einsatz dieser Funktion ist genehmigungspflichtig.
- Weitere Hinweise siehe "man Attack".
+ARGUMENTE
+=========
-SIEHE AUCH:
- "Attack"
- /std/living/combat.c
+ 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/lfun/FilterArmours b/doc/lfun/FilterArmours
index f934933..32a7f2b 100644
--- a/doc/lfun/FilterArmours
+++ b/doc/lfun/FilterArmours
@@ -1,69 +1,99 @@
-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)
+FilterArmours()
+***************
-SIEHE AUCH:
- Wear(), WearArmour(), WearClothing(), Unwear(), UnwearArmour(),
- UnwearClothing()
- P_CLOTHING, P_ARMOURS
- FilterClothing(), QueryArmourByType()
+FUNKTION
+========
-ZULETZT GEAeNDERT:
+ 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/lfun/FilterClothing b/doc/lfun/FilterClothing
index 95b00e3..a7e1d01 100644
--- a/doc/lfun/FilterClothing
+++ b/doc/lfun/FilterClothing
@@ -1,51 +1,80 @@
-FilterClothing
-FUNKTION:
- public object *FilterClothing(closure filterfun, varargs mixed* extra)
-DEFINIERT IN:
- /std/living/clothing.c
+FilterClothing()
+****************
-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.
+FUNKTION
+========
-RUeCKGABEWERT:
- Ein Array von Objekten mit allen passenden Kleidung.
+ public object *FilterClothing(closure filterfun, varargs mixed* extra)
-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");
+DEFINIERT IN
+============
- 3) ueberhaupt alle getragene Kleidung
- object *clothing = PL->FilterClothing(#'objectp)
+ /std/living/clothing.c
-SIEHE AUCH:
- Wear(), WearArmour(), WearClothing(), Unwear(), UnwearArmour(),
- UnwearClothing()
- P_CLOTHING, P_ARMOURS
- FilterArmours(), QueryArmourByType()
-ZULETZT GEAeNDERT:
+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/lfun/FindBestArmours b/doc/lfun/FindBestArmours
index 68e734b..10a5d80 100644
--- a/doc/lfun/FindBestArmours
+++ b/doc/lfun/FindBestArmours
@@ -1,38 +1,64 @@
+
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.
+FUNKTION
+========
- 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.
+ varargs object *FindBestArmours(mixed type, int maxmon, int maxw,
+ mapping minac, mixed restr)
-SIEHE AUCH:
- FindBestWeapon(), CheckFindRestrictions(), EvalArmour()
+
+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/lfun/FindBestWeapon b/doc/lfun/FindBestWeapon
index d0ba8f1..1aaeb0d 100644
--- a/doc/lfun/FindBestWeapon
+++ b/doc/lfun/FindBestWeapon
@@ -1,33 +1,59 @@
+
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.
+FUNKTION
+========
-SIEHE AUCH:
- FindBestArmours(), CheckFindRestrictions(), EvalWeapon()
+ 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/lfun/FindDistantEnemyVictim b/doc/lfun/FindDistantEnemyVictim
index a51c27f..5ea712d 100644
--- a/doc/lfun/FindDistantEnemyVictim
+++ b/doc/lfun/FindDistantEnemyVictim
@@ -1,32 +1,55 @@
+
FindDistantEnemyVictim()
+************************
-FUNKTION:
- object FindDistantEnemyVictim(string wen, object pl, string msg,
- int dist, int dy)
-DEFINIERT IN:
- /std/spellbook.c
+FUNKTION
+========
-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
+ object FindDistantEnemyVictim(string wen, object pl, string msg,
+ int dist, int dy)
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- teams, FindEnemyVictim, FindNearEnemyVictim, FindFarEnemyVictim
+ /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/lfun/FindDistantGroup b/doc/lfun/FindDistantGroup
index 4dedab6..b94e048 100644
--- a/doc/lfun/FindDistantGroup
+++ b/doc/lfun/FindDistantGroup
@@ -1,31 +1,53 @@
+
FindDistantGroup()
+******************
-FUNKTION:
- varargs object *FindDistantGroup(object pl, int who,
- int dist, int dy, int dx)
-DEFINIERT IN:
- /std/spellbook.c
+FUNKTION
+========
-ARGUMENTE:
- pl - Caster
- who - 1=Freunde, -1=Gegner, 0=beide
- dist - Entfernung
- dy - Tiefe (default 100)
- dx - Breite (default 100*MAX_TEAM_ROWLEN)
+ varargs object *FindDistantGroup(object pl, int who,
+ int dist, int dy, int dx)
-BESCHREIBUNG:
- Ermittelt Lebewesen, die sich in Entfernung <dist> in einem Bereich
- der Breite <dx> und Tiefe <dy> befinden.
-RUECKGABEWERT:
- Array mit den gefundenen Lebewesen.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Genauere Hinweise unter "FindDistantGroups".
- Wer sowohl Freunde wie auch Feinde in getrennten Arrays braucht,
- sollte FindDistantGroups statt FindDistantGroup verwenden.
+ /std/spellbook.c
-SIEHE AUCH:
- teams, FindDistantGroups
+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/lfun/FindDistantGroups b/doc/lfun/FindDistantGroups
index 507b72e..efb3354 100644
--- a/doc/lfun/FindDistantGroups
+++ b/doc/lfun/FindDistantGroups
@@ -1,59 +1,85 @@
+
FindDistantGroups()
+*******************
-FUNKTION:
- varargs mixed FindDistantGroups(object pl, int dist, int dy, int dx)
-DEFINIERT IN:
- /std/spellbook.c
+FUNKTION
+========
-ARGUMENTE:
- pl - Caster
- dist - Entfernung
- dy - Tiefe (default 100)
- dx - Breite (default 100*MAX_TEAM_ROWLEN)
+ varargs mixed FindDistantGroups(object pl, int dist, int dy, int dx)
-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 })
+DEFINIERT IN
+============
-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.
+ /std/spellbook.c
-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
+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/lfun/FindEnemyVictim b/doc/lfun/FindEnemyVictim
index 0ab72fc..c5a81a6 100644
--- a/doc/lfun/FindEnemyVictim
+++ b/doc/lfun/FindEnemyVictim
@@ -1,24 +1,47 @@
+
FindEnemyVictim()
+*****************
-FUNKTION:
- object FindEnemyVictim(string wen, object pl, string msg)
-DEFINIERT IN:
- /std/spellbook.c
+FUNKTION
+========
-ARGUMENTE:
- wen - id des gewuenschten Gegners, falls nicht angegeben SelectEnemy.
- pl - Caster.
- msg - Nachricht falls Gegner nicht anwesend ist.
+ object FindEnemyVictim(string wen, object pl, string msg)
-BESCHREIBUNG:
- Findet einen Gegner, z.B. fuer einen Angriffsspruch.
-
-RUECKGABEWERT:
- Der Auserwaehlte :-)
-BEMERKUNGEN:
- Der Gegner wird auf jeden Fall angegriffen.
+DEFINIERT IN
+============
-SIEHE AUCH:
- FindLivingVictim
+ /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/lfun/FindFarEnemyVictim b/doc/lfun/FindFarEnemyVictim
index e43dda6..455cf89 100644
--- a/doc/lfun/FindFarEnemyVictim
+++ b/doc/lfun/FindFarEnemyVictim
@@ -1,30 +1,53 @@
+
FindFarEnemyVictim()
+********************
-FUNKTION:
- object FindFarEnemyVictim(string wen, object pl, string msg,
- int min, int max)
-DEFINIERT IN:
- /std/spellbook.c
+FUNKTION
+========
-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
+ object FindFarEnemyVictim(string wen, object pl, string msg,
+ int min, int max)
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- teams, FindEnemyVictim, FindNearEnemyVictim, FindDistantEnemyVictim
+ /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/lfun/FindGroup b/doc/lfun/FindGroup
index ec1c693..112c76f 100644
--- a/doc/lfun/FindGroup
+++ b/doc/lfun/FindGroup
@@ -1,76 +1,98 @@
+
FindGroup()
+***********
-FUNKTION:
- object*FindGroup(object pl,int who);
-DEFINIERT IN:
- /std/spellbook.c
+FUNKTION
+========
-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
+ object*FindGroup(object pl,int who);
-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.
+DEFINIERT IN
+============
-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>.
+ /std/spellbook.c
-SIEHE AUCH:
- FindGroupN(), FindGroupP(), P_FRIEND, P_NO_GLOBAL_ATTACK
-----------------------------------------------------------------------------
+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/lfun/FindGroupN b/doc/lfun/FindGroupN
index 8364f77..b0104ee 100644
--- a/doc/lfun/FindGroupN
+++ b/doc/lfun/FindGroupN
@@ -1,45 +1,67 @@
+
FindGroupN()
+************
-FUNKTION:
- object*FindGroupN(object pl,int who,int n);
-DEFINIERT IN:
- /std/spellbook.c
+FUNKTION
+========
-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).
+ object*FindGroupN(object pl,int who,int n);
-RUeCKGABEWERT:
- Array mit gefundenen Lebewesen
-BESCHREIBUNG:
- Ausgesucht werden die Lebewesen genauso wie bei FindGroup(), nur
- dass zum Schluss die Anzahl noch begrenzt wird.
+DEFINIERT IN
+============
-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.
+ /std/spellbook.c
-SIEHE AUCH:
- FindGroup(), FindGroupP(), P_FRIEND, P_NO_GLOBAL_ATTACK
-----------------------------------------------------------------------------
+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/lfun/FindGroupP b/doc/lfun/FindGroupP
index efef568..e4c297b 100644
--- a/doc/lfun/FindGroupP
+++ b/doc/lfun/FindGroupP
@@ -1,46 +1,68 @@
+
FindGroupP()
+************
-FUNKTION:
- object*FindGroupP(object pl,int who,int pr);
-DEFINIERT IN:
- /std/spellbook.c
+FUNKTION
+========
-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!
+ object*FindGroupP(object pl,int who,int pr);
-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.
+DEFINIERT IN
+============
-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.
+ /std/spellbook.c
-SIEHE AUCH:
- FindGroup(), FindGroupP(), P_FRIEND, P_NO_GLOBAL_ATTACK
-----------------------------------------------------------------------------
+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/lfun/FindNearEnemyVictim b/doc/lfun/FindNearEnemyVictim
index 86d77ce..4bd0458 100644
--- a/doc/lfun/FindNearEnemyVictim
+++ b/doc/lfun/FindNearEnemyVictim
@@ -1,25 +1,48 @@
+
FindNearEnemyVictim()
+*********************
-FUNKTION:
- object FindNearEnemyVictim(string wen, object pl, string msg)
-DEFINIERT IN:
- /std/spellbook.c
+FUNKTION
+========
-ARGUMENTE:
- wen - id des gewuenschten Gegners, SelectNearEnemy falls n/a.
- pl - Caster.
- msg - Nachricht falls Gegner nicht anwesend ist.
+ object FindNearEnemyVictim(string wen, object pl, string msg)
-BESCHREIBUNG:
- Findet einen im Nahkampf erreichbaren Gegner,
- z.B. fuer einen Angriffsspruch.
-
-RUECKGABEWERT:
- Der Auserwaehlte :-)
-BEMERKUNGEN:
- Der Gegner wird auf jeden Fall angegriffen.
+DEFINIERT IN
+============
-SIEHE AUCH:
- teams, FindEnemyVictim, FindFarEnemyVictim, FindDistantEnemyVictim
+ /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/lfun/FindPotion b/doc/lfun/FindPotion
index 417c89b..5d8cae1 100644
--- a/doc/lfun/FindPotion
+++ b/doc/lfun/FindPotion
@@ -1,49 +1,74 @@
+
FindPotion()
+************
-FUNKTION:
- varargs int FindPotion(string s);
-DEFINIERT IN:
- /std/player/potion.c
+FUNKTION
+========
-ARGUMENTE:
- string s
- Ausgabetext. Wenn 0/Leerstring, wird Default verwendet.
+ varargs int FindPotion(string s);
-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.
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- 0 bei Nichtvergabe, 1 bei erfolgreicher Vergabe.
+ /std/player/potion.c
-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)
+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/lfun/FindRangedTarget b/doc/lfun/FindRangedTarget
index 75970fb..5fa6776 100644
--- a/doc/lfun/FindRangedTarget
+++ b/doc/lfun/FindRangedTarget
@@ -1,40 +1,63 @@
+
FindRangedTarget()
+******************
-FUNKTION:
- static string FindRangedTarget(string str, mapping shoot)
-DEFINIERT IN:
- /std/ranged_weapon.c
+FUNKTION
+========
-ARGUMENTE:
- string str - Schusssyntax
- mapping shoot - Schussdaten
+ static string FindRangedTarget(string str, mapping shoot)
-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'
+DEFINIERT IN
+============
-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
+ /std/ranged_weapon.c
-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
\ No newline at end of file
+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/lfun/Flee b/doc/lfun/Flee
index 6a63d89..995cf26 100644
--- a/doc/lfun/Flee
+++ b/doc/lfun/Flee
@@ -1,57 +1,83 @@
+
Flee()
+******
-FUNKTION:
- public varargs void Flee( object oldenv, int force )
-DEFINIERT IN:
- /sys/living/combat.h
- /std/living/combat.c
+FUNKTION
+========
-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.
+ public varargs void Flee( object oldenv, int force )
-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:
+DEFINIERT IN
+============
-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.
+ /sys/living/combat.h
+ /std/living/combat.c
- 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(),
-----------------------------------------------------------------------------
+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/lfun/FreeHands b/doc/lfun/FreeHands
index 2bed9b0..c876b21 100644
--- a/doc/lfun/FreeHands
+++ b/doc/lfun/FreeHands
@@ -1,36 +1,60 @@
-FreeHands
-FUNKTION:
- public varargs int FreeHands(object ob)
-DEFINIERT IN:
- /std/living/combat.c
+FreeHands()
+***********
-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
+FUNKTION
+========
-BESCHREIBUNG:
- Befreit die Haende eines Livings von ein bestimmten Objekt.
- Es werden _alle_ Haende wieder freigegeben.
+ public varargs int FreeHands(object ob)
-BEISPIELE:
- > halte seil fest
- ...
- this_player()->UseHands(this_object(),2);
- ...
- > lasse seil los
- ...
- this_player()->FreeHands(this_object());
- ...
+DEFINIERT IN
+============
-SIEHE AUCH:
- P_HANDS, P_HANDS_USED_BY
- P_MAX_HANDS, P_USED_HANDS, P_FREE_HANDS
- UseHands
+ /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/lfun/GetAquarium b/doc/lfun/GetAquarium
index cea8d49..3896ac5 100644
--- a/doc/lfun/GetAquarium
+++ b/doc/lfun/GetAquarium
@@ -1,37 +1,59 @@
+
GetAquarium()
+*************
-FUNKTION:
- varargs public string* GetAquarium(object angel)
-ARGUMENTE:
- Das optionale Argument <angel> ist die Angel selbst.
+FUNKTION
+========
-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.
+ varargs public string* GetAquarium(object angel)
-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/
+ARGUMENTE
+=========
-BEISPIEL:
- varargs string* GetAquarium(object angel) {
- return ({"/d/dschungel/rikus/q4e/obj/stichling",
- "/d/dschungel/rikus/q4e/obj/karpfen",
- "/p/seher/partymonster/obj/fisch"});
- }
+ Das optionale Argument <angel> ist die Angel selbst.
-SIEHE AUCH:
- Properties: P_WATER, P_FISH
------------------------------------------------------------------------------
+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/lfun/GetDetail b/doc/lfun/GetDetail
index 4bd7301..7e5a092 100644
--- a/doc/lfun/GetDetail
+++ b/doc/lfun/GetDetail
@@ -1,67 +1,90 @@
+
GetDetail()
+***********
-FUNKTION:
- varargs string GetDetail(string key, string race, int sense)
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-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.
+ varargs string GetDetail(string key, string race, int sense)
-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.
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- Die Beschreibung des Details oder 0, wenn es dieses Detail nicht
- gibt.
+ /std/thing/description.c
-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()
+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/lfun/GetDoorsMapping b/doc/lfun/GetDoorsMapping
index 4c68a9d..68beb0d 100644
--- a/doc/lfun/GetDoorsMapping
+++ b/doc/lfun/GetDoorsMapping
@@ -1,24 +1,46 @@
+
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.
+FUNKTION
+========
-RUECKGABEWERT:
- Das Sehertormapping
+ mapping GetDoorsMapping()
-BEMERKUNGEN:
- Diese Funktion wird von /d/seher/portale/sehertormaster definiert.
-BEISPIELE:
- "/d/seher/portale/sehertormaster"->GetDoorsMapping();
+BESCHREIBUNG
+============
-SIEHE AUCH:
- DoorIsKnown, ShowDoors, Teleport, DiscoverDoor
+ 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/lfun/GetEnemies b/doc/lfun/GetEnemies
index 334d0bf..e288250 100644
--- a/doc/lfun/GetEnemies
+++ b/doc/lfun/GetEnemies
@@ -1,34 +1,53 @@
+
GetEnemies()
+************
-FUNKTION:
- mapping GetEnemies();
-DEFINIERT IN:
- /std/living/combat.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ mapping GetEnemies();
-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().
+DEFINIERT IN
+============
-SIEHE AUCH:
- QueryEnemies(), SetEnemies(), InsertEnemy(), StopHuntFor()
+ /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/lfun/GetExits b/doc/lfun/GetExits
index 03b9306..a235b1f 100644
--- a/doc/lfun/GetExits
+++ b/doc/lfun/GetExits
@@ -1,26 +1,46 @@
+
GetExits()
+**********
-FUNKTION:
- varargs string GetExits(object viewer);
-DEFINIERT IN:
- /std/room/exits
+FUNKTION
+========
-ARGUMENTE:
- viewer
- Derjenige, der sich die Ausgaenge anschaut.
+ varargs string GetExits(object viewer);
-BESCHREIBUNG:
- Es wird eine Liste der fuer viewer sichtbaren Ausgaenge erstellt.
-RUeCKGABEWERT:
- String mit der Liste der sichtbaren Ausgaenge.
+DEFINIERT IN
+============
-SIEHE AUCH:
- AddExit(), AddSpecialExit(), GetExits(),
- RemoveExit(), RemoveSpecialExit(),
- GuardExit(),
- H_HOOK_EXIT_USE, P_EXITS, P_HIDE_EXITS, /std/room/exits.c
- ausgaenge
+ /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/lfun/GetFValue b/doc/lfun/GetFValue
index ac17224..30db195 100644
--- a/doc/lfun/GetFValue
+++ b/doc/lfun/GetFValue
@@ -1,37 +1,47 @@
-FUNKTION:
- varargs int GetFValue(string vname, mapping map, object pl)
+GetFValue()
+***********
-ARGUMENTE:
+FUNKTION
+========
- vname : name des parameters aus dem spellmapping
- map : spellmapping
- pl : caster
+ varargs int GetFValue(string vname, mapping map, object pl)
-BESCHREIBUNG:
+ARGUMENTE
+=========
- Berechnet den Wert und den Factor des Parameters in spellmapping.
+ vname : name des parameters aus dem spellmapping
+ map : spellmapping
+ pl : caster
-RUECKGABEWERT:
+BESCHREIBUNG
+============
- Berechneter Wert*Factor aus dem Spellmapping.
+ Berechnet den Wert und den Factor des Parameters in spellmapping.
-BEMERKUNGEN:
+RUECKGABEWERT
+=============
- Ruft GetValue(vname,map,pl)*GetFactor(vname,map,pl)/100 auf.
+ Berechneter Wert*Factor aus dem Spellmapping.
-BEISPIEL:
+BEMERKUNGEN
+===========
- xxx=GetFValue(SI_SKILLDAMAGE,sinfo,caster);
+ 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"
+ "GetValue", "GetFactor", "GetOffset", "GetValueO", "GetFValueO"
- Ausfuehrliches Beispiel siehe "GetFValueO".
-
+ Ausfuehrliches Beispiel siehe "GetFValueO".
diff --git a/doc/lfun/GetFValueO b/doc/lfun/GetFValueO
index e954e4b..25650fb 100644
--- a/doc/lfun/GetFValueO
+++ b/doc/lfun/GetFValueO
@@ -1,74 +1,85 @@
-FUNKTION:
- varargs int GetFValueO(string vname, mapping map, object pl)
+GetFValueO()
+************
-ARGUMENTE:
+FUNKTION
+========
- vname : name des parameters aus dem spellmapping
- map : spellmapping
- pl : caster
+ varargs int GetFValueO(string vname, mapping map, object pl)
-BESCHREIBUNG:
+ARGUMENTE
+=========
- 'Berechnet' den Wert, den Factor und den Offset des Parameters
- in spellmapping.
+ vname : name des parameters aus dem spellmapping
+ map : spellmapping
+ pl : caster
-RUECKGABEWERT:
+BESCHREIBUNG
+============
- Berechneter (Wert*Factor)/100+Offset aus dem Spellmapping.
+ 'Berechnet' den Wert, den Factor und den Offset des Parameters
+ in spellmapping.
-BEMERKUNGEN:
+RUECKGABEWERT
+=============
- Ruft (GetValue(vname,map,pl)*GetFactor(vname,map,pl))/100+
- GetOffset(vname,map,pl) auf.
+ Berechneter (Wert*Factor)/100+Offset aus dem Spellmapping.
-BEISPIEL:
+BEMERKUNGEN
+===========
- 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]) ])
- ]));
+ Ruft (GetValue(vname,map,pl)*GetFactor(vname,map,pl))/100+
+ GetOffset(vname,map,pl) auf.
- 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.
+BEISPIEL
+========
- Nun die Rechenbeispiele:
+ 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]) ])
+ ]));
- 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
+ So, was sollen uns diese Zeilen sagen?
- 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
+ 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.
- 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.
+ 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"
+ "GetValue", "GetFactor", "GetOffset", "GetFValue", "GetValueO"
diff --git a/doc/lfun/GetFactor b/doc/lfun/GetFactor
index 42812dd..adc6a19 100644
--- a/doc/lfun/GetFactor
+++ b/doc/lfun/GetFactor
@@ -1,37 +1,48 @@
-FUNKTION:
- varargs int GetFactor(string vname, mapping map, object pl)
+GetFactor()
+***********
-ARGUMENTE:
+FUNKTION
+========
- vname : name des parameters aus dem spellmapping
- map : spellmapping
- pl : caster
+ varargs int GetFactor(string vname, mapping map, object pl)
-BESCHREIBUNG:
+ARGUMENTE
+=========
- 'Berechnet' den Factor des Parameters in spellmapping.
+ vname : name des parameters aus dem spellmapping
+ map : spellmapping
+ pl : caster
-RUECKGABEWERT:
+BESCHREIBUNG
+============
- Berechneter Factor aus dem Spellmapping.
+ 'Berechnet' den Factor des Parameters in spellmapping.
-BEMERKUNGEN:
+RUECKGABEWERT
+=============
- Beschraekung auf 10-1000. Werte groesser oder kleiner als diese
- werden 'abgeschnitten'.
+ Berechneter Factor aus dem Spellmapping.
-BEISPIEL:
+BEMERKUNGEN
+===========
- xxx=GetFactor(SI_SKILLDAMAGE,sinfo,caster);
+ 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"
+ "GetValue", "GetOffset", "GetFValue", "GetValueO", "GetFValueO"
- Ausfuehrliches Beispiel siehe "GetFValueO".
+ Ausfuehrliches Beispiel siehe "GetFValueO".
diff --git a/doc/lfun/GetGroupMembers b/doc/lfun/GetGroupMembers
index ef70aa3..8c765d7 100644
--- a/doc/lfun/GetGroupMembers
+++ b/doc/lfun/GetGroupMembers
@@ -1,36 +1,60 @@
+
GetGroupMembers()
-FUNKTION:
- string *GetGroupMembers(string grp)
+*****************
-DEFINIERT IN:
- /p/daemon/materialdb.c (MATERIALDB)
-ARGUMENTE:
- string grp - Gruppenname
+FUNKTION
+========
-BESCHREIBUNG:
- Gibt alle dieser Gruppe zugehoerigen Materialien zurueck. Dazu gut, sich
- einen Ueberblick ueber die aktuelle Liste zu verschaffen.
+ string *GetGroupMembers(string grp)
-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");
- ...
+DEFINIERT IN
+============
-SIEHE AUCH:
- Konzepte: material, materialerkennung
- Grundlegend: P_MATERIAL, /sys/thing/material.h
- Master: AddMaterial(), ConvMaterialList(), MaterialGroup(),
- GroupName(), MaterialName(),
- GetMatMembership()
+ /p/daemon/materialdb.c (MATERIALDB)
-7. Mai 2004 Gloinson
\ No newline at end of file
+
+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/lfun/GetInfoArr b/doc/lfun/GetInfoArr
index ef71482..ba6c4c4 100644
--- a/doc/lfun/GetInfoArr
+++ b/doc/lfun/GetInfoArr
@@ -1,31 +1,55 @@
+
GetInfoArr()
-FUNKTION:
- static mixed *GetInfoArr(string str)
+************
-DEFINIERT IN:
- /std/npc/info.c
-ARGUMENTE:
- string str - Schluesselwort der Frage
+FUNKTION
+========
-BESCHREIBUNG:
- Sucht nach einem Schluesselwort in den abgelegten Antworten
- und gibt die Informationen oder einen 0er-Array zurueck.
+ static mixed *GetInfoArr(string str)
-BEMERKUNGEN:
- Ueberschreibbar :)
-RUECKGABEWERT:
- Siehe Parameter von AddInfo:
+DEFINIERT IN
+============
- Array mit:
- ({ <Infostring> (0 fuer keine Antwort),
- <Indent-String> (Default: 0),
- <Silent> (Default: 0),
- <Casebased> (Default: 0)
- })
+ /std/npc/info.c
-SIEHE AUCH:
- Verwandt: AddInfo, do_frage
+
+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/lfun/GetMatMembership b/doc/lfun/GetMatMembership
index 8859a38..e25e991 100644
--- a/doc/lfun/GetMatMembership
+++ b/doc/lfun/GetMatMembership
@@ -1,55 +1,79 @@
+
GetMatMembership()
-FUNKTION:
- string *GetMatMembership(string mat)
+******************
-DEFINIERT IN:
- /p/daemon/materialdb.c (MATERIALDB)
-ARGUMENTE:
- string mat - ein Material
+FUNKTION
+========
-BESCHREIBUNG:
- Gibt alle Gruppen, denen das Material angehoert zurueck. Geeignet, um
- die Eigenschaften eines Materials zu ueberpruefen.
+ string *GetMatMembership(string mat)
-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);
+DEFINIERT IN
+============
- 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])}));
+ /p/daemon/materialdb.c (MATERIALDB)
- // 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);
+
+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
\ No newline at end of file
+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/lfun/GetOffset b/doc/lfun/GetOffset
index e3eba54..ee982b7 100644
--- a/doc/lfun/GetOffset
+++ b/doc/lfun/GetOffset
@@ -1,38 +1,49 @@
-FUNKTION:
- varargs int GetOffset(string vname, mapping map, object pl)
+GetOffset()
+***********
-ARGUMENTE:
+FUNKTION
+========
- vname : name des parameters aus dem spellmapping
- map : spellmapping
- pl : caster
+ varargs int GetOffset(string vname, mapping map, object pl)
-BESCHREIBUNG:
+ARGUMENTE
+=========
- 'Berechnet' den Offset des Parameters in spellmapping.
+ vname : name des parameters aus dem spellmapping
+ map : spellmapping
+ pl : caster
-RUECKGABEWERT:
+BESCHREIBUNG
+============
- Berechneter Offset aus dem Spellmapping.
+ 'Berechnet' den Offset des Parameters in spellmapping.
-BEMERKUNGEN:
+RUECKGABEWERT
+=============
- Beschraekung auf -10000 bis +10000. Werte groesser oder kleiner
- als diese werden 'abgeschnitten'. Mehr als 100% Bonus oder Malus
- gibts nicht ;-).
+ Berechneter Offset aus dem Spellmapping.
-BEISPIEL:
+BEMERKUNGEN
+===========
- xxx=GetOffset(SI_SKILLDAMAGE,sinfo,caster);
+ 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"
+ "GetValue", "GetFactor", "GetFValue", "GetValueO", "GetFValueO"
- Ausfuehrliches Beispiel siehe "GetFValueO".
+ Ausfuehrliches Beispiel siehe "GetFValueO".
diff --git a/doc/lfun/GetOwner b/doc/lfun/GetOwner
index f6b0f98..92543f0 100644
--- a/doc/lfun/GetOwner
+++ b/doc/lfun/GetOwner
@@ -1,19 +1,38 @@
+
+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";
- }
+FUNKTION
+========
-SIEHE AUCH:
- P_INFO
+ 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/lfun/GetPhiolenInfos b/doc/lfun/GetPhiolenInfos
index 604d697..ccd0f68 100644
--- a/doc/lfun/GetPhiolenInfos
+++ b/doc/lfun/GetPhiolenInfos
@@ -1,97 +1,122 @@
+
+GetPhiolenInfos()
+*****************
+
+
GetPhiolenInfos(L)
+==================
-FUNKTION:
- mixed *GetPhiolenInfos();
-BESCHREIBUNG:
+FUNKTION
+========
- 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.
+ mixed *GetPhiolenInfos();
- 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()
------------------------------------------------------------------------------
+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/lfun/GetReputation b/doc/lfun/GetReputation
index b60cdf8..b27d053 100644
--- a/doc/lfun/GetReputation
+++ b/doc/lfun/GetReputation
@@ -1,26 +1,53 @@
-GetReputation
-FUNKTION:
- public int GetReputation(string repid)
-DEFINIERT IN:
- /std/player/reputation.c
+GetReputation()
+***************
-ARGUMENTE:
- repid
- Eindeutige ID der angefragten Reputation.
-BESCHREIBUNG:
- Liefert den aktuellen Wert der angegebenen Reputation <repid> zurueck.
+FUNKTION
+========
-RUeCKGABEWERT:
- Zahlenwert, Integer.
+ public int GetReputation(string repid)
-BEISPIELE:
- s. reputation
-SIEHE AUCH:
- reputation
- ChangeReputation(), GetReputations()
+DEFINIERT IN
+============
-ZULETZT GEAeNDERT:
+ /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/lfun/GetReputations b/doc/lfun/GetReputations
index 81d571e..134bd2c 100644
--- a/doc/lfun/GetReputations
+++ b/doc/lfun/GetReputations
@@ -1,23 +1,47 @@
-GetReputations
-FUNKTION:
- public mapping GetReputations()
-DEFINIERT IN:
- /std/player/reputation.c
+GetReputations()
+****************
-BESCHREIBUNG:
- Liefert ein Mapping aller im Spieler gespeicherten Reputationen und ihrer
- Werte zurueck.
-RUeCKGABEWERT:
- Mapping ([(string)repid: (int)wert])
+FUNKTION
+========
-BEISPIELE:
- s. repuation
+ public mapping GetReputations()
-SIEHE AUCH:
- reputation
- GetReputation(), GetReputations()
-ZULETZT GEAeNDERT:
+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/lfun/GetValue b/doc/lfun/GetValue
index 1c95119..29eea03 100644
--- a/doc/lfun/GetValue
+++ b/doc/lfun/GetValue
@@ -1,37 +1,46 @@
-FUNKTION:
- varargs int GetValue(string vname, mapping map, object pl)
+GetValue()
+**********
-ARGUMENTE:
+FUNKTION
+========
- vname : name des parameters aus dem spellmapping
- map : spellmapping
- pl : caster
+ varargs int GetValue(string vname, mapping map, object pl)
-BESCHREIBUNG:
+ARGUMENTE
+=========
- 'Berechnet' den Wert des uebergebenen Parameters aus dem
- Spellmapping.
+ vname : name des parameters aus dem spellmapping
+ map : spellmapping
+ pl : caster
-RUECKGABEWERT:
+BESCHREIBUNG
+============
- Berechneter Wert aus dem Spellmapping.
+ 'Berechnet' den Wert des uebergebenen Parameters aus dem
+ Spellmapping.
-BEMERKUNGEN:
+RUECKGABEWERT
+=============
-
+ Berechneter Wert aus dem Spellmapping.
-BEISPIEL:
+BEMERKUNGEN
+===========
- xxx=GetValue(SI_SKILLDAMAGE,sinfo,caster);
+
+BEISPIEL
+========
+
+ xxx=GetValue(SI_SKILLDAMAGE,sinfo,caster);
Siehe auch:
- "GetFactor", "GetOffset", "GetFValue", "GetValueO", "GetFValueO"
+ "GetFactor", "GetOffset", "GetFValue", "GetValueO", "GetFValueO"
- Ausfuehrliches Beispiel siehe "GetFValueO".
+ Ausfuehrliches Beispiel siehe "GetFValueO".
diff --git a/doc/lfun/GetValueO b/doc/lfun/GetValueO
index e55b8f3..e9a7522 100644
--- a/doc/lfun/GetValueO
+++ b/doc/lfun/GetValueO
@@ -1,36 +1,47 @@
-FUNKTION:
- varargs int GetValueO(string vname, mapping map, object pl)
+GetValueO()
+***********
-ARGUMENTE:
+FUNKTION
+========
- vname : name des parameters aus dem spellmapping
- map : spellmapping
- pl : caster
+ varargs int GetValueO(string vname, mapping map, object pl)
-BESCHREIBUNG:
+ARGUMENTE
+=========
- Berechnet den Wert und den Offset des Parameters in spellmapping.
+ vname : name des parameters aus dem spellmapping
+ map : spellmapping
+ pl : caster
-RUECKGABEWERT:
+BESCHREIBUNG
+============
- Berechneter Wert+Offset aus dem Spellmapping.
+ Berechnet den Wert und den Offset des Parameters in spellmapping.
-BEMERKUNGEN:
+RUECKGABEWERT
+=============
- Ruft GetValue(vname,map,pl)+GetOffset(vname,map,pl) auf.
+ Berechneter Wert+Offset aus dem Spellmapping.
-BEISPIEL:
+BEMERKUNGEN
+===========
- xxx=GetValueO(SI_SKILLDAMAGE,sinfo,caster);
+ Ruft GetValue(vname,map,pl)+GetOffset(vname,map,pl) auf.
+
+
+BEISPIEL
+========
+
+ xxx=GetValueO(SI_SKILLDAMAGE,sinfo,caster);
Siehe auch:
- "GetValue", "GetFactor", "GetOffset", "GetFValue", "GetFValueO"
+ "GetValue", "GetFactor", "GetOffset", "GetFValue", "GetFValueO"
- Ausfuehrliches Beispiel siehe "GetFValueO".
+ Ausfuehrliches Beispiel siehe "GetFValueO".
diff --git a/doc/lfun/Gildenproperties b/doc/lfun/Gildenproperties
index 30a16c3..dd5676f 100644
--- a/doc/lfun/Gildenproperties
+++ b/doc/lfun/Gildenproperties
@@ -1,131 +1,186 @@
-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
+Gildenproperties()
+******************
-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
+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
+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
+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.
+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
-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
+ P_NOMAGIC durchzukriegen.
-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
+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
-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
+ 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/lfun/GiveMiniQuest b/doc/lfun/GiveMiniQuest
index c08418c..d208dbd 100644
--- a/doc/lfun/GiveMiniQuest
+++ b/doc/lfun/GiveMiniQuest
@@ -1,43 +1,68 @@
+
GiveMiniQuest()
+***************
-FUNKTION:
- int GiveMiniQuest(object winner)
-DEFINIERT IN:
- /secure/questmaster
+FUNKTION
+========
-ARGUMENTE:
- winner
- Spielerobjekt, das die Quest bestanden hat.
+ int GiveMiniQuest(object winner)
-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());
+DEFINIERT IN
+============
-SIEHE AUCH:
- HasMiniQuest
- /secure/questmaster.h, /secure/questmaster.c
+ /secure/questmaster
-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.
-----------------------------------------------------------------------------
+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/lfun/GiveQuest b/doc/lfun/GiveQuest
index 613a501..daedc6c 100644
--- a/doc/lfun/GiveQuest
+++ b/doc/lfun/GiveQuest
@@ -1,63 +1,86 @@
+
GiveQuest()
+***********
-FUNKTION:
- varargs int GiveQuest(string questname, string message)
-DEFINIERT IN:
- /std/player/quests.c
+FUNKTION
+========
-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.
+ varargs int GiveQuest(string questname, string message)
-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.
+DEFINIERT IN
+============
- 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.
+ /std/player/quests.c
-BEISPIEL:
- int quest;
+ARGUMENTE
+=========
- quest = this_player()->GiveQuest("Zacharias Eispalast");
+ 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.
- 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()
+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/lfun/GroupName b/doc/lfun/GroupName
index 7a81c45..7b819be 100644
--- a/doc/lfun/GroupName
+++ b/doc/lfun/GroupName
@@ -1,63 +1,87 @@
+
GroupName()
-FUNKTION:
- string GroupName(string grp)
+***********
-DEFINIERT IN:
- /p/daemon/materialdb.c (MATERIALDB)
-ARGUMENTE:
- string grp - ein Gruppenname
+FUNKTION
+========
-BESCHREIBUNG:
- Gibt die Langbeschreibung des Gruppennamens zurueck.
+ string GroupName(string grp)
-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.")
+DEFINIERT IN
+============
- // ein weiser Schmied:
- int i;
- string *mat, mname, mgroup;
- mat=m_indices(ob->QueryProp(P_MATERIAL));
- i=sizeof(mat);
+ /p/daemon/materialdb.c (MATERIALDB)
- 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);
+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
\ No newline at end of file
+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/lfun/GuardExit b/doc/lfun/GuardExit
index 1cdf8cc..88da3c9 100644
--- a/doc/lfun/GuardExit
+++ b/doc/lfun/GuardExit
@@ -1,85 +1,111 @@
-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});
- }
+GuardExit()
+***********
-SIEHE AUCH:
- AddExit, AddSpecialExit, RemoveExit
- HRegisterToHook, HRegisterModifier, HUnregisterFromHook
- /doc/std/hooks
-----------------------------------------------------------------------------
-20.02.2016, Zesstra
-22.05.2016, Mupfel (Beispiel korrigiert)
+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/lfun/Halt b/doc/lfun/Halt
index 06bfda4..2fb45e8 100644
--- a/doc/lfun/Halt
+++ b/doc/lfun/Halt
@@ -1,30 +1,52 @@
+
Halt()
+******
-FUNKTION:
- void Halt();
-DEFINIERT IN:
- /std/transport.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ void Halt();
-BESCHREIBUNG:
- Die Fahrt des Transporters wird abgebrochen. Sie muss explizit mit
- Start() wieder aufgenommen werden!
-RUeCKGABEWERT:
- keiner
+DEFINIERT IN
+============
-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.
+ /std/transport.c
-SIEHE AUCH:
- Start(), /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/lfun/HasMiniQuest b/doc/lfun/HasMiniQuest
index 76fc394..c832f00 100644
--- a/doc/lfun/HasMiniQuest
+++ b/doc/lfun/HasMiniQuest
@@ -1,37 +1,59 @@
+
HasMiniQuest()
+**************
-FUNKTION:
- int HasMiniQuest(mixed pl, mixed name)
-DEFINIERT IN:
- /secure/questmaster
+FUNKTION
+========
-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
+ int HasMiniQuest(mixed pl, mixed name)
-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");
+DEFINIERT IN
+============
-SIEHE AUCH:
- GiveMiniQuest(L)
- /secure/questmaster.h, /secure/questmaster.c
+ /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/lfun/HitFunc b/doc/lfun/HitFunc
index 3d22075..2fb9b79 100644
--- a/doc/lfun/HitFunc
+++ b/doc/lfun/HitFunc
@@ -1,68 +1,94 @@
+
HitFunc()
+*********
-FUNKTION:
- int HitFunc(object enemy);
-DEFINIERT IN:
- eigenen Objekten, fuer /std/weapon/combat.c
+FUNKTION
+========
-ARGUMENTE:
- enemy
- Der Gegner, gegen den die Waffe eingesetzt wird.
+ int HitFunc(object enemy);
-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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Wenn durch den Bonus die Genehmigungsgrenzen der Balance
- ueberschritten werden koennen, muss man seinen Regionsmagier und
- die Objekt-Balance konsultieren!
+ eigenen Objekten, fuer /std/weapon/combat.c
- 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().
+ARGUMENTE
+=========
-BEISPIELE:
- Eine Waffe, die gegen Orks besonders gut wirkt:
+ enemy
+ Der Gegner, gegen den die Waffe eingesetzt wird.
- inherit "std/weapon";
- #include <properties.h>
- #include <combat.h>
- #include <class.h>
+BESCHREIBUNG
+============
- 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());
+ 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 */
+ 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 */
- }
+ return 0; /* ansonsten keinen zusaetzlichen Schaden anrichten */
+ }
-SIEHE AUCH:
- QueryDefend(), /std/weapon.c
- TakeFlaw()
-----------------------------------------------------------------------------
+
+SIEHE AUCH
+==========
+
+ QueryDefend(), /std/weapon.c
+ TakeFlaw()
+
11.08.2007, Zesstra
diff --git a/doc/lfun/Identify b/doc/lfun/Identify
index 836e58b..9f55541 100644
--- a/doc/lfun/Identify
+++ b/doc/lfun/Identify
@@ -1,24 +1,43 @@
+
Identify()
+**********
-FUNKTION:
- void Identify(object ob);
-DEFINIERT IN:
- /std/corpse.c
+FUNKTION
+========
-ARGUMENTE:
- ob
- Das kuerzlich nach langem, hartem Kampf verstorbene Objekt.
+ void Identify(object ob);
-BESCHREIBUNG:
- In dieser Funktion werden Lang- und Kurzbeschreibung der Leiche gesetzt
- sowie die Verwesung in Gang gesetzt.
-RUeCKGABEWERT:
- keiner
+DEFINIERT IN
+============
-SIEHE AUCH:
- /std/corpse.c
+ /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/lfun/InFight b/doc/lfun/InFight
index 086c5bd..73fef03 100644
--- a/doc/lfun/InFight
+++ b/doc/lfun/InFight
@@ -1,32 +1,52 @@
+
InFight()
+*********
-FUNKTION:
- mixed InFight()
-ARGUMENTE:
- keine
+FUNKTION
+========
-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.
+ mixed InFight()
-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 ;)
+ARGUMENTE
+=========
-BEMERKUNG:
- InFight() gibt lediglich das Ergebnis von EnemyPresent() zurueck.
+ keine
-SIEHE AUCH:
- EnemyPresent(), PresentEnemies()
- /std/living/combat.c
+
+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/lfun/InList b/doc/lfun/InList
index adcd431..82de3c9 100644
--- a/doc/lfun/InList
+++ b/doc/lfun/InList
@@ -1,28 +1,48 @@
+
InList()
+********
-FUNKTION:
- int InList(object room, int *potionlist, int *knownlist)
-DEFINIERT IN:
- /secure/potionmaster.c
+FUNKTION
+========
-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
+ int InList(object room, int *potionlist, int *knownlist)
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- Sonstiges: zaubertraenke, /room/orakel.c
- Verwandt: FindPotion(), RemoveKnownPotion(), AddKnownPotion()
- Props: P_POTIONROOMS, P_KNOWN_POTIONROOMS
+ /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/lfun/InformAlcoholEffect b/doc/lfun/InformAlcoholEffect
index 0fa5297..4967510 100644
--- a/doc/lfun/InformAlcoholEffect
+++ b/doc/lfun/InformAlcoholEffect
@@ -1,43 +1,65 @@
-InformAlcoholEffect
-FUNKTION:
- void InformAlcoholEffect(object pl, int msgid, int area)
+InformAlcoholEffect()
+*********************
-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.
+FUNKTION
+========
-RUeCKGABEWERT:
- keiner
+ void InformAlcoholEffect(object pl, int msgid, int area)
-SIEHE AUCH:
- P_ALCOHOL, /sys/health.h
-----------------------------------------------------------------------------
+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/lfun/InformDefend b/doc/lfun/InformDefend
index eb36921..d6a401e 100644
--- a/doc/lfun/InformDefend
+++ b/doc/lfun/InformDefend
@@ -1,62 +1,81 @@
+
InformDefend()
+**************
-FUNKTION:
- void InformDefend(object enemy);
-DEFINIERT IN:
- /std/living/combat.c
+FUNKTION
+========
-ARGUMENTE:
- enemy
- Der Feind, der ein zu verteidigendes Lebewesen angegriffen hat.
+ void InformDefend(object enemy);
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- AddDefender(), RemoveDefender(), DefendOther(), Kill(), IsEnemy(),
- P_DEFENDERS, /std/living/combat.c, /sys/new_skills.h
+ /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/lfun/InformRowChange b/doc/lfun/InformRowChange
index e2aa8fc..7e7b804 100644
--- a/doc/lfun/InformRowChange
+++ b/doc/lfun/InformRowChange
@@ -1,23 +1,43 @@
+
InformRowChange()
+*****************
-FUNKTION:
- varargs void InformRowChange(int from, int to, object caster);
-DEFINIERT IN:
- /std/living/team.c
+FUNKTION
+========
-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.
+ varargs void InformRowChange(int from, int to, object caster);
-RUECKGABEWERT:
- Keiner.
-SIEHE AUCH:
- teams
+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/lfun/InformUnwear b/doc/lfun/InformUnwear
index 9471028..01e9886 100644
--- a/doc/lfun/InformUnwear
+++ b/doc/lfun/InformUnwear
@@ -1,29 +1,48 @@
-InformUnwear
-FUNKTION:
- protected void InformUnwear(object pl, int silent, int all)
+InformUnwear()
+**************
-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.
+FUNKTION
+========
-BESCHREIBUNG:
- Diese Funktion wird aufgerufen, wenn die Ruestung erfolgreich
- ausgezogen wurde.
+ protected void InformUnwear(object pl, int silent, int all)
-RUeCKGABEWERT:
- keiner
-SIEHE AUCH:
- InformUnwield(), InformWield(), InformWear()
+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/lfun/InformUnwield b/doc/lfun/InformUnwield
index ef2d9bc..1f10e72 100644
--- a/doc/lfun/InformUnwield
+++ b/doc/lfun/InformUnwield
@@ -1,26 +1,45 @@
-InformUnwield
-FUNKTION:
- protected void InformUnwield(object pl, int silent)
+InformUnwield()
+***************
-DEFINIERT IN:
- /std/weapon/combat.c
-ARGUMENTE:
- pl
- Das Lebewesen, das die Waffe gezueckt hatte.
- silent
- Flag, ob Meldungen unterdruckt werden sollen.
+FUNKTION
+========
-BESCHREIBUNG:
- Diese Funktion wird aufgerufen, wenn die Waffe erfolgreich
- weggesteckt wurde.
+ protected void InformUnwield(object pl, int silent)
-RUeCKGABEWERT:
- keiner
-SIEHE AUCH:
- InformWield(), InformWear(), InformUnwear()
+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/lfun/InformWear b/doc/lfun/InformWear
index 4c7c9b4..6860633 100644
--- a/doc/lfun/InformWear
+++ b/doc/lfun/InformWear
@@ -1,29 +1,48 @@
-InformWear
-FUNKTION:
- protected void InformWear(object pl, int silent, int all)
+InformWear()
+************
-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.
+FUNKTION
+========
-BESCHREIBUNG:
- Diese Funktion wird aufgerufen, wenn die Ruestung erfolgreich
- angezogen wurde.
+ protected void InformWear(object pl, int silent, int all)
-RUeCKGABEWERT:
- keiner
-SIEHE AUCH:
- InformUnwield(), InformWield(), InformUnwear()
+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/lfun/InformWield b/doc/lfun/InformWield
index 67c6b98..0c14c2a 100644
--- a/doc/lfun/InformWield
+++ b/doc/lfun/InformWield
@@ -1,26 +1,45 @@
-InformWield
-FUNKTION:
- protected void InformWield(object pl, int silent)
+InformWield()
+*************
-DEFINIERT IN:
- /std/weapon/combat.c
-ARGUMENTE:
- pl
- Das Lebewesen, das die Waffe gezueckt hat.
- silent
- Flag, ob Meldungen unterdruckt werden sollen.
+FUNKTION
+========
-BESCHREIBUNG:
- Diese Funktion wird aufgerufen, wenn die Waffe erfolgreich
- gezueckt wurde.
+ protected void InformWield(object pl, int silent)
-RUeCKGABEWERT:
- keiner
-SIEHE AUCH:
- InformUnwield(), InformWear(), InformUnwear()
+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/lfun/InsertEnemy b/doc/lfun/InsertEnemy
index 03d1d7d..84885db 100644
--- a/doc/lfun/InsertEnemy
+++ b/doc/lfun/InsertEnemy
@@ -1,28 +1,53 @@
+
+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:
+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/lfun/InsertEnemyTeam b/doc/lfun/InsertEnemyTeam
index e9ade63..b25843d 100644
--- a/doc/lfun/InsertEnemyTeam
+++ b/doc/lfun/InsertEnemyTeam
@@ -1,46 +1,66 @@
InsertEnemyTeam()
+*****************
-FUNKTION:
- varargs void InsertEnemyTeam(mixed ens, int rek)
+FUNKTION
+========
-DEFINIERT IN:
- /std/living/team.c
+ varargs void InsertEnemyTeam(mixed ens, int rek)
-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
+DEFINIERT IN
+============
-RUECKGABEWERT:
- keiner
+ /std/living/team.c
-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
+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/lfun/InsertSensitiveObject b/doc/lfun/InsertSensitiveObject
index c89cef8..534db19 100644
--- a/doc/lfun/InsertSensitiveObject
+++ b/doc/lfun/InsertSensitiveObject
@@ -1,48 +1,68 @@
+
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.
+FUNKTION
+========
-BEMERKUNGEN:
- Setzt man P_SENSITIVE nicht als Default sondern situationsabhaengig,
- dann muss man auch InsertSensitiveObject() im Environment
- auch selbst rufen!
+ void InsertSensitiveObject(object ob, mixed *arg)
-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
+DEFINIERT IN
+============
-SIEHE AUCH:
- P_SENSITIVE
- RemoveSensitiveObject
- insert_sensitive_inv_trigger, insert_sensitive_inv
- P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY, P_SENSITIVE_INVENTORY_TRIGGER
- CheckSensitiveAttack
+ /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/lfun/InternalModifyAttack b/doc/lfun/InternalModifyAttack
index 0ac2d19..2d9f3eb 100644
--- a/doc/lfun/InternalModifyAttack
+++ b/doc/lfun/InternalModifyAttack
@@ -1,37 +1,58 @@
+
+InternalModifyAttack()
+**********************
+
+
InternalModifyAttack(L)
+=======================
-FUNKTION:
- protected void InternalModifyAttack(mapping ainfo)
-DEFINIERT IN:
- /std/living/combat
+FUNKTION
+========
-ARGUMENTE:
- mapping ainfo Werte aus der Attack
+ protected void InternalModifyAttack(mapping ainfo)
-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,
- ]);
+DEFINIERT IN
+============
-SIEHE AUCH:
- InternalModifyDefend(L)
- Attack(L)
+ /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/lfun/InternalModifyDefend b/doc/lfun/InternalModifyDefend
index 93f0d39..3015534 100644
--- a/doc/lfun/InternalModifyDefend
+++ b/doc/lfun/InternalModifyDefend
@@ -1,29 +1,50 @@
+
+InternalModifyDefend()
+**********************
+
+
InternalModifyDefend(L)
+=======================
-FUNKTION:
- protected void InternalModifyDefend(int dam, mixed dt, mixed spell,
- object enemy)
-DEFINIERT IN:
- /std/living/combat
+FUNKTION
+========
-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
+ protected void InternalModifyDefend(int dam, mixed dt, mixed spell,
+ object enemy)
-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)
+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/lfun/IsArmour b/doc/lfun/IsArmour
index 8ef812a..a7e5daf 100644
--- a/doc/lfun/IsArmour
+++ b/doc/lfun/IsArmour
@@ -1,32 +1,55 @@
+
IsArmour()
+**********
-FUNKTION:
- status IsArmour()
-DEFINIERT IN:
- /std/armour/wear.c
+FUNKTION
+========
-RUeCKGABEWERT:
- 1 wenn ein Ruestung
- 0 sonst
+ status IsArmour()
-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.
+DEFINIERT IN
+============
-BEISPIEL:
- // enthaelt im Gegensatz zu P_ARMOURS auch nichtgetragenen Kram
- // im Inventory L1
- object *allarmours =
- filter_objects(all_inventory(this_player()), "IsArmour")
+ /std/armour/wear.c
-SIEHE AUCH:
- Aehnlich: living, interactive
- Aehnlich: IsBottle, IsClothing, IsPlayerCorpse, IsRoom, IsUnit
- Props: P_ARMOURS
+
+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/lfun/IsBottle b/doc/lfun/IsBottle
index 8ac0c96..08f0125 100644
--- a/doc/lfun/IsBottle
+++ b/doc/lfun/IsBottle
@@ -1,21 +1,42 @@
+
+IsBottle()
+**********
+
+
IsPlayerCorpse
+==============
-FUNKTION:
- int IsBottle()
-DEFINIERT IN:
- /std/items/flasche.c
+FUNKTION
+========
-RUeCKGABEWERT:
- 1 wenn Flasche
- 0 sonst
+ int IsBottle()
-BESCHREIBUNG:
- Gibt 1 zurueck, wenn das eine Flasche mit ordentlichem Flaschenverhalten
- ist.
-SIEHE AUCH:
- Aehnlich: living, interactive
- Aehnlich: IsArmour, IsClothing, IsPlayerCorpse, IsRoom, IsUnit
+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/lfun/IsClothing b/doc/lfun/IsClothing
index 843e18d..c51f3f6 100644
--- a/doc/lfun/IsClothing
+++ b/doc/lfun/IsClothing
@@ -1,29 +1,49 @@
+
IsClothing()
+************
-FUNKTION:
- status IsClothing()
-DEFINIERT IN:
- /std/clothing.c
- /std/clothing_container.c
+FUNKTION
+========
-RUeCKGABEWERT:
- 1 wenn ein Kleidungsstueck
- 0 sonst
+ status IsClothing()
-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")
+DEFINIERT IN
+============
-SIEHE AUCH:
- Aehnlich: living, interactive
- Aehnlich: IsArmour, IsBottle, IsPlayerCorpse, IsRoom, IsUnit
- Props: P_CLOTHING
+ /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/lfun/IsEnemy b/doc/lfun/IsEnemy
index c406cd5..45fb1fc 100644
--- a/doc/lfun/IsEnemy
+++ b/doc/lfun/IsEnemy
@@ -1,31 +1,50 @@
+
IsEnemy()
+*********
-FUNKTION:
- int IsEnemy(object wer);
-DEFINIERT IN:
- /std/living/combat.c
+FUNKTION
+========
-ARGUMENTE:
- wer
- Das Objekt, welches darauf ueberprueft werden soll, ob es
- derzeit als Gegner bekannt ist.
+ int IsEnemy(object wer);
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- SelectEnemy(), QueryEnemies(), StopHuntFor()
+ /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/lfun/IsEqual b/doc/lfun/IsEqual
index 806661e..34d142f 100644
--- a/doc/lfun/IsEqual
+++ b/doc/lfun/IsEqual
@@ -1,39 +1,58 @@
+
IsEqual()
+*********
+
FUNKTION
- int IsEqual(object ob)
+========
-DEFINIERT IN:
- /std/unit.c
+ int IsEqual(object ob)
-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.
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- 0 - this_object() ist nicht vom selben Typ wie ob
- 1 - this_object() ist vom gleichen Typ wie ob
+ /std/unit.c
-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));
- }
+ARGUMENTE
+=========
-SIEHE AUCH:
- /std/unit.c
-------------------------------------------------------------------------------
+ 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/lfun/IsPlayerCorpse b/doc/lfun/IsPlayerCorpse
index a92a830..3cccc05 100644
--- a/doc/lfun/IsPlayerCorpse
+++ b/doc/lfun/IsPlayerCorpse
@@ -1,21 +1,38 @@
-IsPlayerCorpse
-FUNKTION:
- public int IsPlayerCorpse()
+IsPlayerCorpse()
+****************
-DEFINIERT IN:
- /std/corpse.c
-RUeCKGABEWERT:
- 1 wenn Spielerleiche
- 0 sonst
+FUNKTION
+========
-BESCHREIBUNG:
- Gibt 1 zurueck, wenn diese Leiche eine Spielerleiche ist. Es kann auch
- eine "normale" NPC-Leiche sein.
+ public int IsPlayerCorpse()
-SIEHE AUCH:
- Aehnlich: living, interactive
- Aehnlich: IsArmour, IsBottle, IsClothing, IsRoom, IsUnit
+
+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/lfun/IsRoom b/doc/lfun/IsRoom
index d595ed0..61ce904 100644
--- a/doc/lfun/IsRoom
+++ b/doc/lfun/IsRoom
@@ -1,21 +1,38 @@
+
IsRoom()
+********
-FUNKTION:
- status IsRoom()
-DEFINIERT IN:
- /std/room.c
+FUNKTION
+========
-RUeCKGABEWERT:
- 1 wenn ein Raum
- 0 sonst
+ status IsRoom()
-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
+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/lfun/IsTeamLeader b/doc/lfun/IsTeamLeader
index eaa008f..1880cc9 100644
--- a/doc/lfun/IsTeamLeader
+++ b/doc/lfun/IsTeamLeader
@@ -1,48 +1,68 @@
IsTeamLeader()
+**************
-FUNKTION:
- object IsTeamLeader()
+FUNKTION
+========
-DEFINIERT IN:
- /std/living/team.c
+ object IsTeamLeader()
-ARGUMENTE:
- keine
-BESCHREIBUNG:
- Testet, ob der Spieler ein Teamleiter ist.
+DEFINIERT IN
+============
-RUECKGABEWERT:
- Falls der Spieler Teamleiter ist, wird das Teamobjekt zurueckgegeben,
- sonst 0.
+ /std/living/team.c
-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!";
- }
+ARGUMENTE
+=========
-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
+ 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/lfun/IsTeamMove b/doc/lfun/IsTeamMove
index 844b041..584dc13 100644
--- a/doc/lfun/IsTeamMove
+++ b/doc/lfun/IsTeamMove
@@ -1,40 +1,60 @@
IsTeamMove()
+************
-FUNKTION:
- object IsTeamMove()
+FUNKTION
+========
-DEFINIERT IN:
- /std/living/team.c
+ object IsTeamMove()
-ARGUMENTE:
- keine
-BESCHREIBUNG:
- Testet, ob momentan die Angriffsbewegung ausgefuehrt wird.
+DEFINIERT IN
+============
-RUECKGABEWERT:
- Falls die Angriffsbewegung gerade ausgefuehrt wird, wird das
- Teamobjekt zurueckgegeben, sonst 0.
+ /std/living/team.c
-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
+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/lfun/IsUnit b/doc/lfun/IsUnit
index bce8ab0..230f09e 100644
--- a/doc/lfun/IsUnit
+++ b/doc/lfun/IsUnit
@@ -1,23 +1,42 @@
+
IsUnit()
+********
-FUNKTION:
- int IsUnit();
-DEFINIERT IN:
- /std/unit.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ int IsUnit();
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- /std/unit.c
+ /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/lfun/Kill b/doc/lfun/Kill
index a8e4540..1125345 100644
--- a/doc/lfun/Kill
+++ b/doc/lfun/Kill
@@ -1,24 +1,43 @@
+
Kill()
+******
-FUNKTION:
- int Kill(object enemy)
-ARGUMENTE:
- enemy: Der boese, boese Feind.
+FUNKTION
+========
-BESCHREIBUNG:
- Nach Aufruf der Funktion wird der Feind in jedem
- heart_beat() attackiert.
+ int Kill(object enemy)
-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:
+ARGUMENTE
+=========
-SIEHE AUCH:
- InsertEnemy
+ 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/lfun/LearnSkill b/doc/lfun/LearnSkill
index 6373fbb..caab276 100644
--- a/doc/lfun/LearnSkill
+++ b/doc/lfun/LearnSkill
@@ -1,35 +1,53 @@
+
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
+FUNKTION
+========
-BESCHREIBUNG:
- Die Methode laesst einen interaktiven (eingeloggten) Spieler den
- Skill 'sname' um 'add' Punkte lernen.
+ public varargs void LearnSkill(string sname, int add, int diff)
- 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.
+DEFINIERT IN
+============
-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
+ /std/living/skills.c
-3. Okt 2011 Gloinson
\ No newline at end of file
+
+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/lfun/Leave b/doc/lfun/Leave
index b3b52d2..fef5e6f 100644
--- a/doc/lfun/Leave
+++ b/doc/lfun/Leave
@@ -1,40 +1,64 @@
+
Leave()
+*******
-FUNKTION:
- int Leave();
-DEFINIERT IN:
- /std/transport.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ int Leave();
-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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Es werden keine Tests durchgefuehrt, ob der Transporter ueberhaupt
- angesprochen wurde! Das muss man selber machen.
+ /std/transport.c
-BEISPIELE:
- int myLeave(string str)
- {
- if (str && id(str))
- return Leave();
+ARGUMENTE
+=========
- notify_fail("Was willst Du verlassen?\n");
- return 0;
- }
+ keine
-SIEHE AUCH:
- Enter(), /std/transport.c
-----------------------------------------------------------------------------
+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/lfun/LimitAbility b/doc/lfun/LimitAbility
index e6a2810..6c31eed 100644
--- a/doc/lfun/LimitAbility
+++ b/doc/lfun/LimitAbility
@@ -1,47 +1,67 @@
+
LimitAbility()
-FUNKTION:
- protected varargs mixed LimitAbility(mixed sinfo, int diff)
+**************
-DEFINIERT IN:
- /std/living/skills.c
-ARGUMENTE:
- mixed sinfo Skill-Informationen
- int diff Schwierigkeit
+FUNKTION
+========
-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%|
+ protected varargs mixed LimitAbility(mixed sinfo, int diff)
-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
+
+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/lfun/MaterialGroup b/doc/lfun/MaterialGroup
index da51cad..1b4e61e 100644
--- a/doc/lfun/MaterialGroup
+++ b/doc/lfun/MaterialGroup
@@ -1,37 +1,64 @@
+
MaterialGroup()
-FUNKTION:
- int MaterialGroup(mapping mats, string grp)
+***************
-DEFINIERT IN:
- /p/daemon/materialdb.c (MATERIALDB)
-ARGUMENTE:
- mapping mats - Materialienmapping
- string grp - Materialiengruppe
+FUNKTION
+========
-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).
+ int MaterialGroup(mapping mats, string grp)
-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");
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Wird von /std/thing/description::QueryMaterialGroup() gerufen.
- Bitte an Objekten auch QueryMaterialGroup() verwenden.
+ /p/daemon/materialdb.c (MATERIALDB)
-SIEHE AUCH:
- Konzepte: material, materialerkennung
- Grundlegend: P_MATERIAL, /sys/thing/material.h
- Master: AddMaterial(), ConvMaterialList()
- GroupName(), MaterialName(),
- GetGroupMembers(), GetMatMembership()
-7. Mai 2004 Gloinson
\ No newline at end of file
+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/lfun/MaterialList b/doc/lfun/MaterialList
index 17ef526..228f7a8 100644
--- a/doc/lfun/MaterialList
+++ b/doc/lfun/MaterialList
@@ -1,65 +1,96 @@
+
+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})
+FUNKTION
+========
-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.
+ varargs string MaterialList(int casus, mixed idinf)
- Wenn ein Spieler etwas identifiziert, sollte auch TP uebergeben werden,
- bei NPCs koennte das anders aussehen.
-RUECKGABEWERT:
- String mit Liste der Materialien.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- - es werden nur die Materialien angegeben, nicht die Menge.
- - ruft ConvMaterialList() an der MATERIALDB
+ /std/thing/description.c
-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."
+ARGUMENTE
+=========
-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
+ 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})
-7. Mai 2004 Gloinson
\ No newline at end of file
+
+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/lfun/MaterialName b/doc/lfun/MaterialName
index 0e338a3..782a9f7 100644
--- a/doc/lfun/MaterialName
+++ b/doc/lfun/MaterialName
@@ -1,72 +1,96 @@
+
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")
+FUNKTION
+========
-BESCHREIBUNG:
- Diese Funktion sucht unter Beruecksichtigung der Erkennungsbe-
- schraenkungen des Materials und Faehigkeiten des Spielers den
- Klarnamen des Materials heraus und gibt den zurueck.
+ varargs string MaterialName(string mat, int casus, mixed idinf)
-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");
- ...
+DEFINIERT IN
+============
- // ein weiser schmied:
- int i;
- string *mat, mname, mgroup;
- mat=m_indices(ob->queryprop(p_material));
- i=sizeof(mat);
+ /p/daemon/materialdb.c (MATERIALDB)
- 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);
+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
\ No newline at end of file
+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/lfun/MayAddObject b/doc/lfun/MayAddObject
index d502da4..1df06ea 100644
--- a/doc/lfun/MayAddObject
+++ b/doc/lfun/MayAddObject
@@ -1,33 +1,55 @@
+
MayAddObject()
+**************
-FUNKTION:
- int MayAddObject(object ob);
-DEFINIERT IN:
- /std/container/restrictions.c
+FUNKTION
+========
-ARGUMENTE:
- ob - Das Object bei dem geprueft werden soll, ob es noch in den
- Container passt.
+ int MayAddObject(object ob);
-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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- invis-Objekte passen immer in den Container hinein!
- move() ruft diese Funktion nicht auf, wenn in den Flags M_NOCHECK
- gesetzt war!
+ /std/container/restrictions.c
-SIEHE AUCH:
- MayAddWeight(), PreventInsert(), move(), /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/lfun/MayAddWeight b/doc/lfun/MayAddWeight
index 1cc4e47..bc8e06d 100644
--- a/doc/lfun/MayAddWeight
+++ b/doc/lfun/MayAddWeight
@@ -1,47 +1,72 @@
+
MayAddWeight()
+**************
-FUNKTION:
- int MayAddWeight(int gewicht);
-DEFINIERT IN:
- /std/container/restrictions.c
+FUNKTION
+========
-ARGUMENTE:
- gewicht
- Das zu pruefende Gewicht.
+ int MayAddWeight(int 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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- move() ruft diese Funktion nicht auf, wenn in den Flags M_NOCHECK
- gesetzt war!
+ /std/container/restrictions.c
-BEISPIELE:
- Die entsprechende Abfrage in /std/thing/moving.c sieht etwa
- folgendermassen aus:
- int weight;
+ARGUMENTE
+=========
- ...
- weight = QueryProp(P_TOTAL_WEIGHT); // Behaelter? Ja => Gesamtgewicht
- if (!weight)
- weight = QueryProp(P_WEIGHT); // Nein: einfaches Gewicht
+ gewicht
+ Das zu pruefende Gewicht.
- if (ziel->MayAddWeight(weight) == -1) // Passt es noch rein?
- return ME_TOO_HEAVY; // Nein, entspr. Fehler zurueckgeben
- ...
+BESCHREIBUNG
+============
-SIEHE AUCH:
- MayAddObject(), PreventInsert(), move(), /std/container/restrictions.c
+ 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/lfun/Message b/doc/lfun/Message
index 3635f6e..bee1d46 100644
--- a/doc/lfun/Message
+++ b/doc/lfun/Message
@@ -1,23 +1,40 @@
+
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
+FUNKTION
+========
-BESCHREIBUNG:
- Einem Spieler wird der Text str uebermittelt.
+ varargs int Message(string str, int flag)
-RUECKGABEWERT:
- 1 bei erfolgreicher Uebermittlung
- 0 wenn der Kobold aktiv war
- <0 wenn Spieler oder verwendetes Verb ignoriert
- werden
-SIEHE AUCH:
- P_IGNORE, TestIgnore()
+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/lfun/ModifyQuestTime b/doc/lfun/ModifyQuestTime
index 0020bad..432a362 100644
--- a/doc/lfun/ModifyQuestTime
+++ b/doc/lfun/ModifyQuestTime
@@ -1,44 +1,66 @@
+
ModifyQuestTime()
+*****************
-FUNKTION:
- int ModifyQuestTime(string questname, int zeit)
-DEFINIERT IN:
- /std/player/quests.c
+FUNKTION
+========
-ARGUMENTE:
- questname
- Questname, wie er im Questmaster eingetragen wurde.
- zeit
- Zeitpunkt, zu dem die Quest geloest wurde
+ int ModifyQuestTime(string questname, int zeit)
-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.
+DEFINIERT IN
+============
-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).
+ /std/player/quests.c
-SIEHE AUCH:
- /secure/questmaster.h, /obj/tools/questtool
- GiveQuest(L)
- mktime(E), dtime(SE)
-----------------------------------------------------------------------------
+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/lfun/ModifySkill b/doc/lfun/ModifySkill
index 8dd622f..70c33ba 100644
--- a/doc/lfun/ModifySkill
+++ b/doc/lfun/ModifySkill
@@ -1,73 +1,98 @@
+
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)
+FUNKTION
+========
-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>]).
+ public varargs void ModifySkill(string sname, mixed val,
+ int diff, string gilde)
- 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.
+DEFINIERT IN
+============
-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");
+ /std/living/skills.c
- // #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");
+ARGUMENTE
+=========
-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
+ 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)
-3. Okt 2011 Gloinson
\ No newline at end of file
+
+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/lfun/ModifySkillAttribute b/doc/lfun/ModifySkillAttribute
index e5b3669..1b4fe40 100644
--- a/doc/lfun/ModifySkillAttribute
+++ b/doc/lfun/ModifySkillAttribute
@@ -1,105 +1,133 @@
+
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)
+FUNKTION
+========
- <value> int oder closure
- Wert des Modifikators
- oder
- eine Closure, welche bei Abfrage des betreffenden SAs
- abgefragt um den Modifikator zu bestimmen.
+ public int ModifySkillAttribute(string atrname, mixed value,
+ int duration)
- <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.)
+DEFINIERT IN
+============
- Der Wert eines Modifikators muss zwischen -1000 und 1000 liegen. Der
- Gesamtwert eines SA kann 10 nicht unter- und 1000 nicht ueberschreiten.
+ /std/living/skill_attributes.c
- 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
+ARGUMENTE
+=========
-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.
+ <atrname> string
+ Name des zu veraendernden Attributes
+ (Definiert in /sys/living/skill_attributes.h)
-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.
+ <value> int oder closure
+ Wert des Modifikators
+ oder
+ eine Closure, welche bei Abfrage des betreffenden SAs
+ abgefragt um den Modifikator zu bestimmen.
-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)
+ <duration> int
+ Dauer in Sekunden
- // 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.
+BESCHREIBUNG
+============
-
-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
+ 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/lfun/More b/doc/lfun/More
index 2e73fa2..c504209 100644
--- a/doc/lfun/More
+++ b/doc/lfun/More
@@ -1,56 +1,80 @@
+
More()
+******
-FUNKTION:
- varargs public void More(string txt, int file,
- mixed ctrl, mixed *ctrlargs, int flags);
-DEFINIERT IN:
- /std/util/pager.c
+FUNKTION
+========
-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.
+ varargs public void More(string txt, int file,
+ mixed ctrl, mixed *ctrlargs, int flags);
-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.
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- keiner
+ /std/util/pager.c
-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:
+ARGUMENTE
+=========
- // Ausgabe eines normalen textes...
- this_player()->More("Einfach nur mal so ein Test...\n");
+ 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.
- // Ausgabe eines kompletten files
- this_player()->More("/etc/WIZRULES", 1);
-SIEHE AUCH:
+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/lfun/NPC_Killed_by b/doc/lfun/NPC_Killed_by
index 37392ba..3b8801d 100644
--- a/doc/lfun/NPC_Killed_by
+++ b/doc/lfun/NPC_Killed_by
@@ -1,13 +1,28 @@
-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
-
+
+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/lfun/NewDoor b/doc/lfun/NewDoor
index 09f5796..c534be5 100644
--- a/doc/lfun/NewDoor
+++ b/doc/lfun/NewDoor
@@ -1,223 +1,252 @@
-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.).
+NewDoor()
+*********
-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.
+FUNKTION
+========
- 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.
+ varargs int NewDoor(string|string* cmds, string dest, string|string* ids,
+ mapping|<int|string|string*>* props);
- 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"
+DEFINIERT IN
+============
- D_SHORT
- Die Kurzbeschreibung der Tuer. Ein "%s" wird durch "geoeffnet"
- bzw. "geschlossen" ersetzt.
+ /std/room/doors.c
- 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."
+ARGUMENTE
+=========
- 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.
+ 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.).
- Default: "Tuer"
- D_GENDER
- Das Geschlecht der Tuer.
+BESCHREIBUNG
+============
- Default: FEMALE
+ 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>.
- 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.
+ Die Kommandos werden bei geoeffneter Tuer in die Liste der sichtbaren
+ Ausgaenge eingefuegt.
- 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!
+ 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.
- D_FUNC2
- String mit dem Namen einer Funktion, die im Zielraum nach dem
- Durchschreiten der Tuer aufgerufen werden soll.
+ 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_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_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" ])
- 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.
+ Default: "Eine Tuer.\n"
- 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.
+ D_SHORT
+ Die Kurzbeschreibung der Tuer. Ein "%s" wird durch "geoeffnet"
+ bzw. "geschlossen" ersetzt.
- 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.
+ 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.
- *** 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().
+ Default: "Eine %se Tuer."
-BEISPIELE:
+ 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.
- ** Dies ist eine gewoehnliche Tuer ohne Besonderheiten und ohne
- Extra-Beschreibung:
+ Default: "Tuer"
- NewDoor("sueden","/players/rochus/room/test1");
+ D_GENDER
+ Das Geschlecht der Tuer.
- ** Ein Portal:
+ Default: FEMALE
- 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",
- ]) );
+ 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.
- 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"
+ 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"
}) );
-
- ** Tueren mit Bewegungsmeldung:
- NewDoor("norden","/room/see2",
- ({ D_MSGS, ({"nach Norden","schwimmt",
- "kommt hereingeschwommen"}) }) );
+ Im Startraum:
- ** Eine Tuer mit Testfunktion:
+ void view()
+ {
+ write("Der Angestellte wirft Dir einen missbilligenden Blick zu, "
+ "laesst Dich aber passieren.\n");
+ }
- NewDoor("osten","/mein/zielraum",
- ({ D_TESTFUNC, "blocker_da" }) );
+ Im Zielraum:
- 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");
- }
+ 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()
+SIEHE AUCH
+==========
------------------------------------------------------------------------------
+ QueryDoorKey(), QueryDoorStatus(), SetDoorStatus(),
+ /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
+
08.02.2015, Arathorn
-
diff --git a/doc/lfun/NoParaObjects b/doc/lfun/NoParaObjects
index 804e7b7..4b6013a 100644
--- a/doc/lfun/NoParaObjects
+++ b/doc/lfun/NoParaObjects
@@ -1,28 +1,46 @@
+
+NoParaObjects()
+***************
+
********************** VERALTETE LFUN ****************************
NoParaObjects()
-FUNKTION:
- int NoParaObjects()
-DEFINIERT IN:
- /std/virtual/v_compiler.c
+FUNKTION
+========
-RUeCKGABEWERT:
- 1, wenn der VC keine Parawelt-Objekte erzeugt,
- 0, wenn er es doch tut.
+ int NoParaObjects()
-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!
+DEFINIERT IN
+============
-SIEHE AUCH:
- virtual_compiler, P_PARA, QueryValidObject
+ /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/lfun/NotifyDestruct b/doc/lfun/NotifyDestruct
index 48e71ee..31e02e9 100644
--- a/doc/lfun/NotifyDestruct
+++ b/doc/lfun/NotifyDestruct
@@ -1,47 +1,66 @@
+
NotifyDestruct()
+****************
-FUNKTION:
- public int|string NotifyRemove(object zerstoerer);
-ARGUMENTE:
- zerstoerer
- Das Objekt, welches destruct() auf dieses Objekt anwendet.
+FUNKTION
+========
-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.
+ public int|string NotifyRemove(object zerstoerer);
- 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.
+ARGUMENTE
+=========
-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.
+ zerstoerer
+ Das Objekt, welches destruct() auf dieses Objekt anwendet.
-SIEHE AUCH:
- NotifyLeave(), NotifyInsert(), NotifyRemove()
-----------------------------------------------------------------------------
+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/lfun/NotifyInsert b/doc/lfun/NotifyInsert
index aa2c6ec..fa2f2ac 100644
--- a/doc/lfun/NotifyInsert
+++ b/doc/lfun/NotifyInsert
@@ -1,28 +1,47 @@
+
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.
+FUNKTION
+========
-BESCHREIBUNG:
- Diese Funktion wird im Behaelter aufgerufen, nachdem ein Objekt in
- besagten Behaelter hinein bewegt wurde.
+ void NotifyInsert(object ob, object oldenv);
-RUeCKGABEWERT:
- keiner
-BEMERKUNGEN:
- Diese Funktion wird nur im Falle unbelebter Objekte gerufen. Fuer
- Lebewesen s. bitte. init().
+ARGUMENTE
+=========
-SIEHE AUCH:
- NotifyLeave(), PreventInsert(), PreventLeave(), move(), NotifyRemove()
- exit(), init(), NotifyMove(), PreventMove()
+ 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/lfun/NotifyLeave b/doc/lfun/NotifyLeave
index 621fca8..fbfc1c3 100644
--- a/doc/lfun/NotifyLeave
+++ b/doc/lfun/NotifyLeave
@@ -1,28 +1,47 @@
+
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.
+FUNKTION
+========
-BESCHREIBUNG:
- Diese Funktion wird im Behaelter aufgerufen, nachdem ein Objekt aus
- besagten Behaelter entfernt wurde.
+ void NotifyLeave(object ob, object dest);
-RUeCKGABEWERT:
- keiner
-BEMERKUNGEN:
- Diese Funktion wird nur im Falle unbelebter Objekte gerufen. Fuer
- Lebewesen s. bitte. exit().
+ARGUMENTE
+=========
-SIEHE AUCH:
- NotifyRemove(), NotifyInsert(), PreventInsert(), PreventLeave(), move(),
- exit(), init(), NotifyMove(), PreventMove()
+ 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/lfun/NotifyMove b/doc/lfun/NotifyMove
index 9fe1861..18261f8 100644
--- a/doc/lfun/NotifyMove
+++ b/doc/lfun/NotifyMove
@@ -1,58 +1,83 @@
-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");
- }
+NotifyMove()
+************
-SIEHE AUCH:
- PreventLeave(), NotifyInsert(), NotifyLeave(), MayAddObject(),
- PreventInsertLiving(), PreventLeaveLiving(), NotifyMove(),
- PreventMove(), MayAddWeight(), move(), /std/container/restrictions.c
+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/lfun/NotifyPlayerDeath b/doc/lfun/NotifyPlayerDeath
index 9166150..96678ea 100644
--- a/doc/lfun/NotifyPlayerDeath
+++ b/doc/lfun/NotifyPlayerDeath
@@ -1,74 +1,99 @@
+
NotifyPlayerDeath()
+*******************
-FUNKTION:
- void NotifyPlayerDeath(object victim,object killer,int lost_exp);
-DEFINIERT IN:
- /std/player/life.c
+FUNKTION
+========
-ARGUMENTE:
- victim
- Getoeteter Spieler.
- killer
- Objekt, welches den Spieler getoetet hat.
- lost_exp
- Erfahrungspunkte, die der Spieler durch den Tod verloren hat.
+ void NotifyPlayerDeath(object victim,object killer,int lost_exp);
-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.
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- keiner
+ /std/player/life.c
-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) );
- }
+ARGUMENTE
+=========
- 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.
+ victim
+ Getoeteter Spieler.
+ killer
+ Objekt, welches den Spieler getoetet hat.
+ lost_exp
+ Erfahrungspunkte, die der Spieler durch den Tod verloren hat.
- 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
-----------------------------------------------------------------------------
+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/lfun/NotifyRemove b/doc/lfun/NotifyRemove
index 48b04fa..2604b77 100644
--- a/doc/lfun/NotifyRemove
+++ b/doc/lfun/NotifyRemove
@@ -1,26 +1,45 @@
+
NotifyRemove()
+**************
-FUNKTION:
- void NotifyRemove(object ob);
-ARGUMENTE:
- ob
- Das Objekt, das aus dem Behaelter entfernt wurde.
+FUNKTION
+========
-BESCHREIBUNG:
- Diese Funktion wird im Behaelter aufgerufen, wenn ein Objekt im
- besagten Behaelter zerstoert wird.
+ void NotifyRemove(object ob);
-RUeCKGABEWERT:
- keiner
-BEMERKUNGEN:
- Wird nicht gerufen, wenn ein Spielerobjekt zerstoert wird.
+ARGUMENTE
+=========
-SIEHE AUCH:
- NotifyLeave(), NotifyInsert(), PreventInsert(), PreventLeave(), move(),
- NotifyMove(), PreventMove(),
- BecomesNetDead()
+ 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/lfun/NotifyTimedAttrModExpired b/doc/lfun/NotifyTimedAttrModExpired
index f59a79a..09dc168 100644
--- a/doc/lfun/NotifyTimedAttrModExpired
+++ b/doc/lfun/NotifyTimedAttrModExpired
@@ -1,20 +1,38 @@
-NotifyTimedAttrModExpired
-FUNKTION:
- void NotifyTimedAttrModExpired(string key)
-DEFINIERT IN:
- Push-Methode in notify-Objekten.
+NotifyTimedAttrModExpired()
+***************************
-ARGUMENTE:
- string key - der geloeschte Modifier
-BESCHREIBUNG:
- Wird aus dem Lebewesen aus aufgerufen, in dem der entsprechenden
- Modifier soeben ungueltig geworden ist.
+FUNKTION
+========
-SIEHE AUCH:
- Properties: P_ATTRIBUTES, P_TIMED_ATTR_MOD
- Methoden: SetTimedAttrModifier(L), DeleteTimedAttrModifier(L),
- QueryTimedAttrModifier(L)
+ 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/lfun/NotifyXMAttrModLimitViolation b/doc/lfun/NotifyXMAttrModLimitViolation
index 44f39c0..f3c54a4 100644
--- a/doc/lfun/NotifyXMAttrModLimitViolation
+++ b/doc/lfun/NotifyXMAttrModLimitViolation
@@ -1,20 +1,35 @@
+
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
\ No newline at end of file
+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/lfun/Pacify b/doc/lfun/Pacify
index b90ed83..feca7bf 100644
--- a/doc/lfun/Pacify
+++ b/doc/lfun/Pacify
@@ -1,113 +1,146 @@
+
+Pacify()
+********
+
+
FUNKTION
- public int Pacify(object caster)
+========
+
+ public int Pacify(object caster)
+
DEFINIERT IN
- /std/living/combat.c
+============
+
+ /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.
+ Diese Funktion versucht, ein Lebewesen zu befrieden.
+ Will eine Gilde ein Lebewesen befrieden, muss sie hierfuer diese Funktion
+ in dem Lebewesen aufrufen.
- 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.
+ Ein immer befriedbarer NPC kann durch das Setzen von P_ACCEPT_PEACE in einem
+ Lebewesen realisiert werden.
- Je oefter ein Lebewesen als von einer Gilde schon befriedet wurde, desto
- unwahrscheinlicher, dass es erneut darauf 'hereinfaellt'.
+ 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.
-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
+
+ 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
+==========
+
+ P_ACCEPT_PEACE, P_PEACE_HISTORY
+
LETZTE AENDERUNG
-07.06.2008, Zesstra
+================
+07.06.2008, Zesstra
diff --git a/doc/lfun/PayIn b/doc/lfun/PayIn
index 0714c53..35616de 100644
--- a/doc/lfun/PayIn
+++ b/doc/lfun/PayIn
@@ -1,47 +1,73 @@
+
PayIn()
-FUNKTION:
- varargs void PayIn(int amount, int percent);
+*******
-DEFINIERT IN:
- /p/daemon/zentralbank.c
-ARGUMENTE:
- int amount - einzuzahlender Betrag
- int percent - Bewertungsprozentsatz
+FUNKTION
+========
-BESCHREIBUNG:
- Es wird Brutto amount Geld in die Bank eingezahlt. Der Prozentsatz legt
- fest, wieviel tatsaechlich gutgeschrieben wird:
- Gutschrift = amount*percent/100
+ varargs void PayIn(int amount, int percent);
- 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");
- ...
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Unsere Zentralbank ist korrupt, vor allem dadurch, dass in Laeden und
- an anderen Stellen Geld erzeugt wird.
+ /p/daemon/zentralbank.c
-SIEHE AUCH:
- Geldhandling: AddMoney(L), QueryMoney(L)
- Zentralbank: WithDraw(L), _query_current_money(L)
- Sonstiges: /items/money.c, /sys/bank.h
+
+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/lfun/PlayerQuit b/doc/lfun/PlayerQuit
index 22e3d6e..0eb8fbf 100644
--- a/doc/lfun/PlayerQuit
+++ b/doc/lfun/PlayerQuit
@@ -1,20 +1,37 @@
+
PlayerQuit()
+************
-FUNKTION:
- void PlayerQuit(object pl);
-GERUFEN VON:
- /std/player/base.c
+FUNKTION
+========
-ARGUMENTE:
- object pl
- Spieler, der Verbindung beendet
+ void PlayerQuit(object pl);
-BESCHREIBUNG:
- Wird im environment() gerufen, wenn der Spieler das MUD mit "ende"
- verlaesst.
-SIEHE AUCH:
- BecomesNetAlive(), BecomesNetDead()
-
-24. Aug 2011 Gloinson
\ No newline at end of file
+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/lfun/PresentEnemies b/doc/lfun/PresentEnemies
index 9c31efe..12ac650 100644
--- a/doc/lfun/PresentEnemies
+++ b/doc/lfun/PresentEnemies
@@ -1,71 +1,95 @@
-FUNKTION:
- object *PresentEnemies();
-DEFINIERT IN:
- /std/living/combat.c
+PresentEnemies()
+****************
-ARGUMENTE:
- keine
-RUeCKGABEWERT:
- anwesende Feinde
+FUNKTION
+========
-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.
+ object *PresentEnemies();
-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
+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/lfun/PresentEnemyRows b/doc/lfun/PresentEnemyRows
index 339642c..003d6c3 100644
--- a/doc/lfun/PresentEnemyRows
+++ b/doc/lfun/PresentEnemyRows
@@ -1,40 +1,60 @@
PresentEnemyRows()
+******************
-FUNKTION:
- varargs mixed *PresentEnemyRows(object *here)
+FUNKTION
+========
-DEFINIERT IN:
- /std/living/team.c
+ varargs mixed *PresentEnemyRows(object *here)
-ARGUMENTE:
- Rueckgabewert von PresentEnemies kann uebergeben werden.
-BESCHREIBUNG:
- Ergibt die feindlichen Reihen.
+DEFINIERT IN
+============
-RUECKGABEWERT:
- Ein Array, bestehend aus MAX_TEAMROWS Arrays mit den Objekten
- der anwesenden Feinde.
+ /std/living/team.c
-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
+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/lfun/PresentPosition b/doc/lfun/PresentPosition
index ea765cf..c94d129 100644
--- a/doc/lfun/PresentPosition
+++ b/doc/lfun/PresentPosition
@@ -1,38 +1,58 @@
PresentPosition()
+*****************
-FUNKTION:
- varargs int PresentPosition(mixed pmap)
+FUNKTION
+========
-DEFINIERT IN:
- /std/living/team.c
+ varargs int PresentPosition(mixed pmap)
-ARGUMENTE:
- Rueckgabewert von PresentTeamRows() oder PresentTeamPositions()
- kann uebergeben werden.
-BESCHREIBUNG:
- Ergibt die Nummer der Reihe, in der der Spieler gerade steht.
+DEFINIERT IN
+============
-RUECKGABEWERT:
- Reihennummer im Bereich von 1 bis TEAM_MAXROWS.
+ /std/living/team.c
-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
+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/lfun/PresentRows b/doc/lfun/PresentRows
index e8c854a..37e3ab8 100644
--- a/doc/lfun/PresentRows
+++ b/doc/lfun/PresentRows
@@ -1,88 +1,120 @@
PresentRows()
+*************
-FUNKTION:
- mixed *PresentRows(object env);
+FUNKTION
+========
-DEFINIERT IN:
- TEAM_OBJECT (s. <living/team.h>)
+ mixed *PresentRows(object env);
-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.
+DEFINIERT IN
+============
-RUECKGABEWERT:
- Es wird ein mixed-Array zurueckgegeben, dabei sind die einzelnen Reihen
- selbst wiederum Arrays mit den Spielerobjekten.
+ TEAM_OBJECT (s. <living/team.h>)
-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.
+ARGUMENTE
+=========
- void Attack( object enemy )
- {
- ...
+ object env
+ Das Environment des gewuenschten Objektes.
- object team = enemy->QueryProp(P_TEAM);
- if ( objectp(team) )
- {
- mixed teamrows = team->PresentRows(enemy);
+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.
+// 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");
+ 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_SHOW_DAMAGE:1]),TO);
- }
- }
- }
- else
- {
- tell_object(enemy,"Der Feuerteufel laesst eine Feuerwalze auf Dich "
- "los.\n");
+ pl->Defend(200+random(200),({DT_FIRE}),([SP_S
+ HOW_DAMAGE:1]),TO);
- enemy->Defend(200+random(200),({DT_FIRE}),([SP_SHOW_DAMAGE: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
+ 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/lfun/PresentTeamPositions b/doc/lfun/PresentTeamPositions
index 76adc17..3af354b 100644
--- a/doc/lfun/PresentTeamPositions
+++ b/doc/lfun/PresentTeamPositions
@@ -1,40 +1,60 @@
PresentTeamPositions()
+**********************
-FUNKTION:
- varargs mapping PresentTeamPositions(mixed pmap)
+FUNKTION
+========
-DEFINIERT IN:
- /std/living/team.c
+ varargs mapping PresentTeamPositions(mixed pmap)
-ARGUMENTE:
- Rueckgabewert von PresentTeamRows() kann uebergeben werden.
-BESCHREIBUNG:
- Ermittelt die Reihennummern aller anwesender Teammitglieder.
+DEFINIERT IN
+============
-RUECKGABEWERT:
- Ein Mapping mit den Reihennummern (von 1 bis MAX_TEAMROWS)
- der anwesenden Teammitglieder.
+ /std/living/team.c
-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
+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/lfun/PresentTeamRows b/doc/lfun/PresentTeamRows
index 38bfa7e..7875918 100644
--- a/doc/lfun/PresentTeamRows
+++ b/doc/lfun/PresentTeamRows
@@ -1,24 +1,47 @@
+
PresentTeamRows()
+*****************
-FUNKTION:
- mixed *PresentTeamRows()
-DEFINIERT IN:
- /std/living/team.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ mixed *PresentTeamRows()
-BESCHREIBUNG:
- Ergibt die Reihen mit den anwesenden Teammitgliedern.
-RUECKGABEWERT:
- Ein Array bestehend aus MAX_TEAMROWS Arrays mit den Objekten
- der anwesenden Teammitglieder.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Wenn der Spieler in keinem Team ist, enthaelt das erste Array
- nur den Spieler und die anderen Arrays sind leer.
+ /std/living/team.c
-SIEHE AUCH:
- teams
+
+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/lfun/PreventFollow b/doc/lfun/PreventFollow
index 100f92d..c3de6b1 100644
--- a/doc/lfun/PreventFollow
+++ b/doc/lfun/PreventFollow
@@ -1,49 +1,72 @@
+
PreventFollow()
+***************
-FUNKTION:
- int PreventFollow(object dest)
-ARGUMENTE:
- dest: Zielobjekt, in das der Verfolgte bewegt werden soll.
+FUNKTION
+========
-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.
+ int PreventFollow(object dest)
-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.
+ARGUMENTE
+=========
-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.
+ dest: Zielobjekt, in das der Verfolgte bewegt werden soll.
- #define PATH(x) ("/d/.../.../mein/pfad/+(x)")
- ...
+FUNKTION
+========
- int PreventFollow(object boot)
- {
- if ( object_name(boot)[0..strlen(PATH("boot"))-1] == PATH("boot") )
- return 1;
- }
+ 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.
- 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
\ No newline at end of file
+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/lfun/PreventInsert b/doc/lfun/PreventInsert
index 55c1533..3635142 100644
--- a/doc/lfun/PreventInsert
+++ b/doc/lfun/PreventInsert
@@ -1,46 +1,71 @@
+
PreventInsert()
+***************
-FUNKTION:
- int PreventInsert(object ob);
-DEFINIERT IN:
- /std/container/restrictions.c
+FUNKTION
+========
-ARGUMENTE:
- ob
- Das Objekt, das in den Behaelter eingefuegt werden soll.
+ int PreventInsert(object ob);
-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.
+DEFINIERT IN
+============
-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!
+ /std/container/restrictions.c
-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);
- }
+ARGUMENTE
+=========
-SIEHE AUCH:
- PreventLeave(), NotifyInsert(), NotifyLeave(), MayAddObject(),
- PreventInsertLiving(), PreventLeaveLiving(), NotifyMove(),
- PreventMove(), MayAddWeight(), move(), /std/container/restrictions.c
+ 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/lfun/PreventInsertLiving b/doc/lfun/PreventInsertLiving
index 78f431f..fbde29f 100644
--- a/doc/lfun/PreventInsertLiving
+++ b/doc/lfun/PreventInsertLiving
@@ -1,35 +1,56 @@
+
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()
+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/lfun/PreventLeave b/doc/lfun/PreventLeave
index 85d46a3..24c33d2 100644
--- a/doc/lfun/PreventLeave
+++ b/doc/lfun/PreventLeave
@@ -1,35 +1,57 @@
+
PreventLeave()
+**************
-FUNKTION:
- int PreventLeave(object ob, mixed dest);
-DEFINIERT IN:
- /std/container/restrictions.c
+FUNKTION
+========
-ARGUMENTE:
- ob
- Das Objekt, das aus dem Behaelter genommen werden soll.
- dest
- Das Ziel in das das Objekt ob bewegt werden soll.
+ int PreventLeave(object ob, mixed dest);
-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.
+DEFINIERT IN
+============
-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!
+ /std/container/restrictions.c
-SIEHE AUCH:
- PreventInsert(), NotifyInsert(), NotifyLeave(),
- MayAddWeight(), move(), /std/container/restrictions.c
- PreventLeaveLiving(), PreventInsertLiving(), PreventMove(),
- NotifyMove(), MayAddObject(), NotifyRemove()
-----------------------------------------------------------------------------
+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/lfun/PreventLeaveLiving b/doc/lfun/PreventLeaveLiving
index 4d13b54..20a5844 100644
--- a/doc/lfun/PreventLeaveLiving
+++ b/doc/lfun/PreventLeaveLiving
@@ -1,35 +1,58 @@
+
PreventLeaveLiving()
+********************
-FUNKTION:
- int PreventLeaveLiving(object ob, mixed dest);
-DEFINIERT IN:
- /std/container/restrictions.c
+FUNKTION
+========
-ARGUMENTE:
- ob
- Das Living, das aus dem Behaelter genommen werden soll.
- dest
- Das Ziel in das das Living ob bewegt werden soll.
+ int PreventLeaveLiving(object ob, mixed dest);
-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.
+DEFINIERT IN
+============
-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!
+ /std/container/restrictions.c
-SIEHE AUCH:
- PreventInsertLiving(), /std/container/restrictions.c
- PreventMove(), PreventLeave(), PreventInsert(),
- NotifyMove(), NotifyLeave(), NotifyInsert(), NotifyRemove(),
- move(), exit(), init(),
- InitAttack, ExitAttack()
-----------------------------------------------------------------------------
+
+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/lfun/PreventMove b/doc/lfun/PreventMove
index 798ee0b..920372d 100644
--- a/doc/lfun/PreventMove
+++ b/doc/lfun/PreventMove
@@ -1,81 +1,109 @@
+
+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
+FUNKTION
+========
-ARGUMENTE:
- dest
- Das Ziel des Moves
- oldenv
- Das (Noch-)Environment des Objekts
- method
- Die Move-Methode(n), mit der/denen bewegt werden soll
+ protected int PreventMove(object dest, object oldenv, int method);
-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.
+DEFINIERT IN
+============
-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_!
+ /std/thing/moving.c
+ /std/living/moving.c
+ /std/player/moving.c
-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);
+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
+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/lfun/Query b/doc/lfun/Query
index 2b39998..27c2d9e 100644
--- a/doc/lfun/Query
+++ b/doc/lfun/Query
@@ -1,81 +1,108 @@
+
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.
+FUNKTION
+========
-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:
+ public varargs mixed Query(string name, int Type);
- 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'.
+DEFINIERT IN
+============
-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).
+ /std/thing/properties.c
-BEISPIELE:
- // Auslesen des Wertes unter Umgehung einer Abfragemethode
- Query(P_XYZ, F_VALUE);
- // Auslesen der Flags erfaehrt man mit:
- Query(P_XYZ, F_MODE);
+ARGUMENTE
+=========
- // 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);
- ...
- }
+ string name - Property, deren Wert(e) ausgelesen werden
+ int type - Art der gewuenschten Information.
-SIEHE AUCH:
- Aehnliches: SetProp(L), QueryProp(L), Set(L)
- Generell: SetProperties(L), QueryProperties(L)
- Konzept: properties, /std/thing/properties.c
- Sonstiges: P_AUTOLOADOBJ
+
+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/lfun/QueryAllDoors b/doc/lfun/QueryAllDoors
index 3bbbfbb..cdf7140 100644
--- a/doc/lfun/QueryAllDoors
+++ b/doc/lfun/QueryAllDoors
@@ -1,32 +1,52 @@
-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).
+QueryAllDoors()
+***************
-SIEHE AUCH:
- NewDoor(), QueryDoorKey(), QueryDoorStatus(), SetDoorStatus(),
- /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), P_DOOR_INFOS
+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/lfun/QueryArmourByType b/doc/lfun/QueryArmourByType
index 22d43e9..20fcab5 100644
--- a/doc/lfun/QueryArmourByType
+++ b/doc/lfun/QueryArmourByType
@@ -1,64 +1,91 @@
+
+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:
+FUNKTION
+========
- 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?
+ 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(
- "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
+ "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
+
+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/lfun/QueryArrived b/doc/lfun/QueryArrived
index 33cf887..9c4de60 100644
--- a/doc/lfun/QueryArrived
+++ b/doc/lfun/QueryArrived
@@ -1,26 +1,45 @@
+
QueryArrived()
+**************
-FUNKTION:
- mixed QueryArrived();
-DEFINIERT IN:
- /std/transport.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ mixed QueryArrived();
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- AddRoute(), /std/transport.c
+ /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/lfun/QueryArticle b/doc/lfun/QueryArticle
index 0993b3e..3be5ecc 100644
--- a/doc/lfun/QueryArticle
+++ b/doc/lfun/QueryArticle
@@ -1,92 +1,118 @@
+
QueryArticle()
+**************
-FUNKTION:
- varargs string QueryArticle(int casus, int dem, int force);
-DEFINIERT IN:
- /std/thing/language.c
+FUNKTION
+========
-ARGUMENTE:
- casus
- Der Fall, in dem der Artikel gewuenscht wird.
- (Konstanten aus /sys/thing/language.h: WER, WEM, WESSEN, WEN.)
+ varargs string QueryArticle(int casus, int dem, int force);
- 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.
+DEFINIERT IN
+============
-BESCHREIBUNG:
- Diese Funktion gibt einen zum Geschlecht des Objektes passenden Artikel
- zurueck, der in den passenden Fall dekliniert wird.
+ /std/thing/language.c
- 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.
+ARGUMENTE
+=========
-BEMERKUNGEN:
- Achtung: bei gueltigem Artikel wird ein Leerzeichen angehaengt!
+ casus
+ Der Fall, in dem der Artikel gewuenscht wird.
+ (Konstanten aus /sys/thing/language.h: WER, WEM, WESSEN, WEN.)
- 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."
+ 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!
-RUeCKGABEWERT:
- * gewuenschter Artikel als String plus Leerzeichen (!) ODER
- * Leerstring
+ force
+ Falls ungleich Null, so wird auf jeden Fall ein Artikel
+ zurueckgegeben, trotz P_ARTICLE == 0.
-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}));
+BESCHREIBUNG
+============
- // "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 ...
+ Diese Funktion gibt einen zum Geschlecht des Objektes passenden Artikel
+ zurueck, der in den passenden Fall dekliniert wird.
-SIEHE AUCH:
- Aehnlich: SuggestArticle(), query_c_article(), query_g_suffix()
- Sonstiges: QueryOwn(), QueryDu(),
- QueryPronoun(), QueryPossPronoun()
- DeclAdj()
- name()
+ 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/lfun/QueryAttribute b/doc/lfun/QueryAttribute
index 60a68c9..978c6c0 100644
--- a/doc/lfun/QueryAttribute
+++ b/doc/lfun/QueryAttribute
@@ -1,32 +1,59 @@
+
QueryAttribute()
-FUNKTION:
- int QueryAttribute(string attr)
+****************
-DEFINIERT IN:
- /std/living/attributes.c
-ARGUMENTE:
- attr - interessierendes Gesamtattribut
+FUNKTION
+========
-BESCHREIBUNG:
- Das Attribut samt seiner Offsets (Modifier) wird zurueckgegeben.
+ int QueryAttribute(string attr)
-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");
+DEFINIERT IN
+============
-BENERKUNGEN:
- Wenn es um Attributabfragen geht, bitte diese Methode verwenden!
+ /std/living/attributes.c
-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
+
+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/lfun/QueryAttributeOffset b/doc/lfun/QueryAttributeOffset
index f938ab8..b16d10c 100644
--- a/doc/lfun/QueryAttributeOffset
+++ b/doc/lfun/QueryAttributeOffset
@@ -1,26 +1,47 @@
+
QueryAttributeOffset()
-FUNKTION:
- int QueryAttributeOffset(string attr)
+**********************
-DEFINIERT IN:
- /std/living/attributes.c
-ARGUMENTE:
- attr - gesuchter AttributOffset
+FUNKTION
+========
-BESCHREIBUNG:
- Die Offsets des Attributs (inklusive Modifier) werden zurueckgegeben.
+ int QueryAttributeOffset(string attr)
-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
+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/lfun/QueryBuyFact b/doc/lfun/QueryBuyFact
index 435e8be..3f728c3 100644
--- a/doc/lfun/QueryBuyFact
+++ b/doc/lfun/QueryBuyFact
@@ -1,22 +1,41 @@
+
QueryBuyFact()
+**************
-FUNKTION:
- int QueryBuyFact();
-DEFINIERT IN:
- /std/laden.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ int QueryBuyFact();
-BESCHREIBUNG:
- Gibt den mit SetBuyFact() gesetzten Faktor zurueck.
-RUeCKGABEWERT:
- Der Einkaufspreismultiplikator.
+DEFINIERT IN
+============
-SIEHE AUCH:
- SetBuyFact(), /std/laden.c
+ /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/lfun/QueryBuyValue b/doc/lfun/QueryBuyValue
index 261a435..cecc57c 100644
--- a/doc/lfun/QueryBuyValue
+++ b/doc/lfun/QueryBuyValue
@@ -1,52 +1,56 @@
-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
\ No newline at end of file
+
+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/lfun/QueryCoinsPerUnits b/doc/lfun/QueryCoinsPerUnits
index 948c1b0..7261758 100644
--- a/doc/lfun/QueryCoinsPerUnits
+++ b/doc/lfun/QueryCoinsPerUnits
@@ -1,31 +1,57 @@
+
+QueryCoinsPerUnits()
+********************
+
+
QueryCoinsPerUnit()
+===================
-FUNKTION:
- int *QueryCoinsPerUnits();
-DEFINIERT IN:
- /std/unit.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ int *QueryCoinsPerUnits();
-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.
+DEFINIERT IN
+============
-BEISPIELE:
- Steht im Unit-Objekt folgende Wertzuweisung:
+ /std/unit.c
- SetCoinsPerUnits(7,2);
- so liefert QueryCoinsPerUnits() als Ergebnis ({7, 2}).
+ARGUMENTE
+=========
-SIEHE AUCH:
- SetCoinsPerUnits(), SetGramsPerUnits(), QueryGramsPerUnit(),
- /std/unit.c
+ 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/lfun/QueryDamage b/doc/lfun/QueryDamage
index 99c4fed..812636a 100644
--- a/doc/lfun/QueryDamage
+++ b/doc/lfun/QueryDamage
@@ -1,39 +1,61 @@
+
QueryDamage()
+*************
-FUNKTION:
- int QueryDamage(object enemy);
-DEFINIERT IN:
- /std/weapon/combat.c
+FUNKTION
+========
-ARGUMENTE:
- enemy
- Der Gegner, gegen den die Waffe eingesetzt wird.
+ int QueryDamage(object enemy);
-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.
+DEFINIERT IN
+============
- Wurde eine HitFunc() angegeben, so wird diese mit den gleichen
- Parametern wie QueryDamage() aufgerufen.
+ /std/weapon/combat.c
-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!
+ARGUMENTE
+=========
-SIEHE AUCH:
- HitFunc(), Attack(), /std/weapon.c, grenzwerte
+ 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/lfun/QueryDefend b/doc/lfun/QueryDefend
index 4d3d3e0..fa3fb11 100644
--- a/doc/lfun/QueryDefend
+++ b/doc/lfun/QueryDefend
@@ -1,45 +1,68 @@
+
QueryDefend()
+*************
-FUNKTION:
- int QueryDefend(string|string* dtyp, int|mapping spell, object enemy);
-DEFINIERT IN:
- /std/armour/combat.c
+FUNKTION
+========
-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
+ int QueryDefend(string|string* dtyp, int|mapping spell, object enemy);
-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
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- Die Ruestungsstaerke in dieser Kampfrunde. Sie ermittelt sich als
- Zufallszahl zwischen 0 und P_AC, zuzueglich des Ergebnisses des
- DefendFunc()-Aufrufs.
+ /std/armour/combat.c
-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)
+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/lfun/QueryDisguise b/doc/lfun/QueryDisguise
index c30aa3f..3cf4b8d 100644
--- a/doc/lfun/QueryDisguise
+++ b/doc/lfun/QueryDisguise
@@ -1,29 +1,51 @@
+
QueryDisguise()
+***************
-FUNKTION:
- mixed QueryDisguise();
-DEFINIERT IN:
- ???
+FUNKTION
+========
-ARGUMENTE:
- keine
+ mixed QueryDisguise();
-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.
+DEFINIERT IN
+============
-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
-----------------------------------------------------------------------------
+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/lfun/QueryDoorKey b/doc/lfun/QueryDoorKey
index cfd6a29..f606c52 100644
--- a/doc/lfun/QueryDoorKey
+++ b/doc/lfun/QueryDoorKey
@@ -1,48 +1,71 @@
-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"
- });
- }
+QueryDoorKey()
+**************
-SIEHE AUCH:
- NewDoor(), QueryDoorStatus(), SetDoorStatus(), P_DOOR_INFOS,
- /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
+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/lfun/QueryDoorStatus b/doc/lfun/QueryDoorStatus
index c1ee6b8..74f7034 100644
--- a/doc/lfun/QueryDoorStatus
+++ b/doc/lfun/QueryDoorStatus
@@ -1,28 +1,48 @@
-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
+QueryDoorStatus()
+*****************
-SIEHE AUCH:
- NewDoor(), QueryDoorKey(), SetDoorStatus(), P_DOOR_INFOS,
- /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
+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/lfun/QueryDu b/doc/lfun/QueryDu
index 9be62a8..aa184cc 100644
--- a/doc/lfun/QueryDu
+++ b/doc/lfun/QueryDu
@@ -1,39 +1,61 @@
+
QueryDu()
+*********
-FUNKTION:
- varargs string QueryDu(int casus, int gender, int anzahl);
-DEFINIERT IN:
- /std/thing/language.c
+FUNKTION
+========
-ARGUMENTE:
- casus
- Der Fall fuer die Anrede.
+ varargs string QueryDu(int casus, int gender, int anzahl);
- gender
- Das Geschlecht des anzuredenden Objektes.
- anzahl
- Ist nur ein Objekt anzusprechen oder mehrere?
+DEFINIERT IN
+============
-BESCHREIBUNG:
- Diese Funktion liefert die dem Anlass entsprechende Anrede fuer ein
- Objekt.
+ /std/thing/language.c
-RUeCKGABEWERT:
- Ein String mit der Anrede.
-BEISPIELE:
+ARGUMENTE
+=========
- printf("%s setzt %s auf den Boden.\n",
- capitalize(QueryDu(WER, TP->QueryProp(P_GENDER), SINGULAR),
- QueryDu(WEN, TP->QueryProp(P_GENDER), SINGULAR));
+ casus
+ Der Fall fuer die Anrede.
- (In den meisten Faellen kann man hier auch direkt "Du" und "dich"
- einsetzen.)
+ gender
+ Das Geschlecht des anzuredenden Objektes.
-SIEHE AUCH:
- /std/thing/language.c
- QueryPossPronoun(), QueryOwn(), QueryPronoun()
-----------------------------------------------------------------------------
+ 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/lfun/QueryEnemies b/doc/lfun/QueryEnemies
index 7c393b4..fc00c0e 100644
--- a/doc/lfun/QueryEnemies
+++ b/doc/lfun/QueryEnemies
@@ -1,33 +1,54 @@
-FUNKTION:
- mixed QueryEnemies();
-DEFINIERT IN:
- /std/living/combat.c
+QueryEnemies()
+**************
-ARGUMENTE:
- keine
-RUeCKGABEWERT:
- Array mit Array aus bekannten Gegnern und Array aus Zeiten
+FUNKTION
+========
-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().
+ mixed QueryEnemies();
-SIEHE AUCH:
- Kill(), Attack(), Defend(), do_my_heart_beat(), PresentEnemies(),
- GetEnemies(), SelectEnemy(), QueryPreferedEnemy(), P_PREFERED_ENEMY
-----------------------------------------------------------------------------
+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/lfun/QueryFlaw b/doc/lfun/QueryFlaw
index 8137d81..e12a119 100644
--- a/doc/lfun/QueryFlaw
+++ b/doc/lfun/QueryFlaw
@@ -1,41 +1,63 @@
+
QueryFlaw()
+***********
-FUNKTION:
- mixed *QueryFlaw();
-DEFINIERT IN:
- /std/armour/combat.c,
- /std/weapon/combat.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ mixed *QueryFlaw();
-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
+DEFINIERT IN
+============
-BEISPIELE:
- Den aktuellen Abnutzungsgrad einer Ruestung kann man sich wie folgt
- anzeigen lassen:
+ /std/armour/combat.c,
+ /std/weapon/combat.c
- mixed *flaw;
- flaw = ruestung->QueryFlaw();
+ARGUMENTE
+=========
- 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]));
+ keine
-SIEHE AUCH:
- TakeFlaw(), /std/armour/combat.c, /std/weapon/combat.c
-----------------------------------------------------------------------------
+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/lfun/QueryGenderString b/doc/lfun/QueryGenderString
index 967a16e..845758f 100644
--- a/doc/lfun/QueryGenderString
+++ b/doc/lfun/QueryGenderString
@@ -1,23 +1,42 @@
+
QueryGenderString()
+*******************
-FUNKTION:
- string QueryGenderString();
-DEFINIERT IN:
- /std/thing/language.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ string QueryGenderString();
-BESCHREIBUNG:
- Es wird ein String mit dem Geschlecht des Objektes zurueckgegeben
- ("maennlich", "weiblich", "saechlich").
-RUeCKGABEWERT:
- Der String mit dem Geschlecht.
+DEFINIERT IN
+============
-SIEHE AUCH:
- /std/thing/language.c
+ /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/lfun/QueryGramsPerUnits b/doc/lfun/QueryGramsPerUnits
index 3549e54..62d5580 100644
--- a/doc/lfun/QueryGramsPerUnits
+++ b/doc/lfun/QueryGramsPerUnits
@@ -1,31 +1,53 @@
+
QueryGramsPerUnits()
+********************
-FUNKTION:
- int *QueryGramsPerUnits();
-DEFINIERT IN:
- /std/unit.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ int *QueryGramsPerUnits();
-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.
+DEFINIERT IN
+============
-BEISPIELE:
- Steht im Unit-Objekt folgende Gewichtszuweisung:
+ /std/unit.c
- SetGramsPerUnits(4,1);
- so liefert QueryGramsPerUnits() als Ergebnis ({4, 1}).
+ARGUMENTE
+=========
-SIEHE AUCH:
- SetCoinsPerUnits(), QueryCoinsPerUnits() SetGramsPerUnits(),
- /std/unit.c
+ 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/lfun/QueryGroupedKeys b/doc/lfun/QueryGroupedKeys
index ce7e316..5101e8d 100644
--- a/doc/lfun/QueryGroupedKeys
+++ b/doc/lfun/QueryGroupedKeys
@@ -1,26 +1,44 @@
+
QueryGroupedKeys()
+******************
-FUNKTION:
- mixed *QueryGroupedKeys()
-DEFINIERT IN:
- /secure/questmaster.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ mixed *QueryGroupedKeys()
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- GiveQuest, QueryQuest, /secure/questmaster.h
+ /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/lfun/QueryGuest b/doc/lfun/QueryGuest
index cc9971b..61cfb04 100644
--- a/doc/lfun/QueryGuest
+++ b/doc/lfun/QueryGuest
@@ -1,33 +1,54 @@
+
QueryGuest()
-FUNKTION:
- int QueryGuest();
+************
-DEFINIERT IN:
- /std/player/base
-BESCHREIBUNG:
- Auf der uid basierende Hilfsfunktion, um Gaeste zu identifizieren.
+FUNKTION
+========
-RUeCKGABEWERT:
- 1, wenn Spielerobjekt ein Gast ist; 0 sonst
+ int QueryGuest();
-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()
+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/lfun/QueryHealInfo b/doc/lfun/QueryHealInfo
index 07b7542..cc42fbc 100644
--- a/doc/lfun/QueryHealInfo
+++ b/doc/lfun/QueryHealInfo
@@ -1,26 +1,45 @@
+
QueryHealInfo()
+***************
-FUNKTION:
- string QueryHealInfo();
-DEFINIERT IN:
- /std/corpse.c,
+FUNKTION
+========
-ARGUMENTE:
- keine
+ string QueryHealInfo();
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- /std/corpse.c, P_HEAL
+ /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/lfun/QueryMaterial b/doc/lfun/QueryMaterial
index 71e3a33..94a5367 100644
--- a/doc/lfun/QueryMaterial
+++ b/doc/lfun/QueryMaterial
@@ -1,34 +1,62 @@
+
+QueryMaterial()
+***************
+
+
QueryMaterial(L)
-FUNKTION:
- int QueryMaterial(string mat)
+================
-DEFINIERT IN:
- /std/thing/description.c
-ARGUMENTE:
- string mat - Material, auf das getestet werden soll
+FUNKTION
+========
-BESCHREIBUNG:
- Testet, ob ein Gegenstand aus dem angegebenen Material besteht
- und gibt dessen Anteil zurueck.
- Die Rueckgabe ist im Wertebereich -100 (Antigruppen) bis +100 (%).
+ int QueryMaterial(string mat)
-RUECKGABEWERT:
- Anteil in Prozent.
-BEISPIELE:
- if(ob->QueryMaterial(MAT_IVORY)<=0)
- write("Daraus kannst Du keine Billiardkugeln schnitzen!\n");
+DEFINIERT IN
+============
-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
+ /std/thing/description.c
-7. Mai 2004 Gloinson
\ No newline at end of file
+
+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/lfun/QueryMaterialGroup b/doc/lfun/QueryMaterialGroup
index c3b6860..3365f73 100644
--- a/doc/lfun/QueryMaterialGroup
+++ b/doc/lfun/QueryMaterialGroup
@@ -1,50 +1,81 @@
+
+QueryMaterialGroup()
+********************
+
+
QueryMaterialGroup(L)
-FUNKTION:
- int QueryMaterialGroup(string grp)
+=====================
-DEFINIERT IN:
- /std/thing/description.c
-ARGUMENTE:
- string grp - Materialgruppe, auf die getestet werden soll
+FUNKTION
+========
-BESCHREIBUNG:
- Liefert eine Angabe, zu welchem Anteil das Objekt aus Materialien
- dieser Gruppe besteht.
- Die Rueckgabe ist im Wertebereich -100 (Antigruppen) bis +100 (%).
+ int QueryMaterialGroup(string grp)
-RUECKGABEWERT:
- Anteil in Prozent.
-BEMERKUNGEN:
- Ruft MaterialGroup() an der MATERIALDB.
+DEFINIERT IN
+============
-BEISPIELE:
- // kann man damit was anfangen?
- if(ob->QueryMaterialGroup(MATGROUP_METAL)<50)
- write("Der Schmied sagt: Daraus kann ich kein Schwert fertigen.\n");
+ /std/thing/description.c
- // 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));
+ARGUMENTE
+=========
-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
+ string grp - Materialgruppe, auf die getestet werden soll
-7. Mai 2004 Gloinson
\ No newline at end of file
+
+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/lfun/QueryMaxQP b/doc/lfun/QueryMaxQP
index 9fa0f5a..7b5aba2 100644
--- a/doc/lfun/QueryMaxQP
+++ b/doc/lfun/QueryMaxQP
@@ -1,27 +1,45 @@
+
QueryMaxQP()
+************
-FUNKTION:
- int QueryMaxQP()
-DEFINIERT IN:
- /secure/questmaster.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ int QueryMaxQP()
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- GiveQuest, QueryQuest, /secure/questmaster.h, QueryGroupedKeys,
- QueryOptQP, QueryTotalQP
+ /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/lfun/QueryMoney b/doc/lfun/QueryMoney
index 899b50e..775a65c 100644
--- a/doc/lfun/QueryMoney
+++ b/doc/lfun/QueryMoney
@@ -1,28 +1,49 @@
+
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.
+FUNKTION
+========
-RUECKGABEWERT:
- Geldmenge im Besitz des abgefragten Spielers
+ int QueryMoney()
-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
+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/lfun/QueryName b/doc/lfun/QueryName
index d26cd1a..71e65e3 100644
--- a/doc/lfun/QueryName
+++ b/doc/lfun/QueryName
@@ -1,24 +1,43 @@
+
QueryName()
+***********
-FUNKTION:
- mixed QueryName();
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ mixed QueryName();
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- QueryProp(), Name(), name(), /std/thing/description.c
+ /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/lfun/QueryOpenMiniQuestsForPlayer b/doc/lfun/QueryOpenMiniQuestsForPlayer
index 40246ae..f43d7cc 100644
--- a/doc/lfun/QueryOpenMiniQuestsForPlayer
+++ b/doc/lfun/QueryOpenMiniQuestsForPlayer
@@ -1,54 +1,80 @@
-FUNKTION:
- mapping QueryOpenMiniQuestsForPlayer(object player)
-DEFINIERT IN:
- /secure/questmaster
+QueryOpenMiniQuestsForPlayer()
+******************************
-BESCHREIBUNG:
- Diese Funktion gibt die Liste der offenen Miniquests des Spielers als
- Mapping zurueck.
-ARGUMENTE:
- player - das interessierende Spielerobjekt
+FUNKTION
+========
-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.
+ mapping QueryOpenMiniQuestsForPlayer(object player)
- 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 ])
+DEFINIERT IN
+============
- Jedes abfragende Objekt muss daher dieses Mapping zunaecht geeignet
- auf seinen Inhalt pruefen, um zu ermitteln, welche Meldung jeweils
- auszugeben ist.
+ /secure/questmaster
-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
+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/lfun/QueryOwn b/doc/lfun/QueryOwn
index b1a55f6..22e9e5f 100644
--- a/doc/lfun/QueryOwn
+++ b/doc/lfun/QueryOwn
@@ -1,32 +1,53 @@
+
QueryOwn()
+**********
-FUNKTION:
- varargs string QueryOwn(int casus)
-DEFINIERT IN:
- /std/thing/language.c
+FUNKTION
+========
-ARGUMENTE:
- casus
- Der Fall fuer die Anrede.
+ varargs string QueryOwn(int casus)
-BESCHREIBUNG:
- Diese Funktion liefert das dem Anlass entsprechende Possessiv-
- pronomen fuer den Spieler selber (Dein/Deine).
-RUeCKGABEWERT:
- Ein String mit dem Pronomen.
+DEFINIERT IN
+============
-BEISPIELE:
+ /std/thing/language.c
- 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.)
+ARGUMENTE
+=========
-SIEHE AUCH:
- /std/thing/language.c
+ 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/lfun/QueryPassengers b/doc/lfun/QueryPassengers
index a71af67..d6f9331 100644
--- a/doc/lfun/QueryPassengers
+++ b/doc/lfun/QueryPassengers
@@ -1,29 +1,51 @@
+
QueryPassengers()
+*****************
-FUNKTION:
- object *QueryPassengers();
-DEFINIERT IN:
- /std/transport.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ object *QueryPassengers();
-BESCHREIBUNG:
- Diese Funktion ermittelt die momentan auf dem Transporter befindlichen
- Passagiere.
-RUeCKGABEWERT:
- Array von Objekten mit den Passagieren.
+DEFINIERT IN
+============
-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!
+ /std/transport.c
-SIEHE AUCH:
- /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/lfun/QueryPosition b/doc/lfun/QueryPosition
index 4d5179d..08af6fe 100644
--- a/doc/lfun/QueryPosition
+++ b/doc/lfun/QueryPosition
@@ -1,29 +1,48 @@
+
QueryPosition()
+***************
-FUNKTION:
- string *QueryPosition();
-DEFINIERT IN:
- /std/transport.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ string *QueryPosition();
-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().
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- Array mit zwei Strings. Der erste String gibt den Kennzeichner der
- momentanen Fahrplanstation an, der zweite String den Kennzeichner der
- naechsten Fahrplanstation.
+ /std/transport.c
-SIEHE AUCH:
- AddRoute(), AddMsg(), AddFun(), /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/lfun/QueryPossPronoun b/doc/lfun/QueryPossPronoun
index c3f4106..90af78a 100644
--- a/doc/lfun/QueryPossPronoun
+++ b/doc/lfun/QueryPossPronoun
@@ -1,48 +1,74 @@
+
QueryPossPronoun()
+******************
-FUNKTION:
- varargs string QueryPossPronoun(mixed what, int casus, int anzahl);
-DEFINIERT IN:
- /std/thing/language.c
+FUNKTION
+========
-ARGUMENTE:
- what
- Geschlecht des Objektes, das besessen wird, oder das Objekt
- selbst.
+ varargs string QueryPossPronoun(mixed what, int casus, int anzahl);
- casus
- Der Fall, in dem das Objekt besessen wird.
- anzahl
- Handelt es sich um nur ein Objekt oder um mehrere?
+DEFINIERT IN
+============
-BESCHREIBUNG:
- Diese Funktion gibt ein Possessivpronomen zurueck, das das
- Besitzverhaeltnis eines Objektes zu diesem Objekt anzeigt.
+ /std/thing/language.c
-RUeCKGABEWERT:
- Das Possessivpronomen im entsprechenden Fall.
-BEMERKUNGEN:
- what und casus beziehen sich auf das Objekt, welches besessen wird, und
- nicht auf den Besitzer!!!
+ARGUMENTE
+=========
-BEISPIELE:
- Um eine korrekte Ausgabe beim Haendeklatschen zu erreichen, koennte man
- zB. folgende Zeile verwenden:
+ what
+ Geschlecht des Objektes, das besessen wird, oder das Objekt
+ selbst.
- printf("%s klatscht in %s Haende.\n",this_player()->name(WER),
- this_player()->QueryPossPronoun(FEMALE, WEN, PLURAL));
+ casus
+ Der Fall, in dem das Objekt besessen wird.
- FEMALE, da "die Hand" weiblich ist, WEN, da man im Akkusativ klatscht,
- und PLURAL, da man dazu beide Haende braucht.
+ anzahl
+ Handelt es sich um nur ein Objekt oder um mehrere?
- 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
-----------------------------------------------------------------------------
+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/lfun/QueryPrayRoom b/doc/lfun/QueryPrayRoom
index 0a097d3..b783174 100644
--- a/doc/lfun/QueryPrayRoom
+++ b/doc/lfun/QueryPrayRoom
@@ -1,33 +1,50 @@
+
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
+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/lfun/QueryPreferedEnemy b/doc/lfun/QueryPreferedEnemy
index 267d27d..10a8ae0 100644
--- a/doc/lfun/QueryPreferedEnemy
+++ b/doc/lfun/QueryPreferedEnemy
@@ -1,35 +1,56 @@
-FUNKTION:
- object QueryPreferedEnemy();
-DEFINIERT IN:
- /std/living/combat.c
+QueryPreferedEnemy()
+********************
-ARGUMENTE:
- keine
-RUeCKGABEWERT:
- bevorzugter Gegner
+FUNKTION
+========
-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.
+ object QueryPreferedEnemy();
-SIEHE AUCH:
- SelectEnemy(), IsEnemy(), P_PREFERED_ENEMY
-----------------------------------------------------------------------------
+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/lfun/QueryPronoun b/doc/lfun/QueryPronoun
index fd041cb..39088f9 100644
--- a/doc/lfun/QueryPronoun
+++ b/doc/lfun/QueryPronoun
@@ -1,32 +1,54 @@
+
QueryPronoun()
+**************
-FUNKTION:
- string QueryPronoun(int casus);
-DEFINIERT IN:
- /std/thing/language.c
+FUNKTION
+========
-ARGUMENTE:
- casus
- Der Fall, in dem das Personalpronomen verlangt wird.
+ string QueryPronoun(int casus);
-BESCHREIBUNG:
- Es wird ein Personalpronomen ("er", "sie", "es") im entsprechenden Fall
- fuer dieses Objekt berechnet.
-RUeCKGABEWERT:
- Das Pronomen im entsprechenden Fall.
+DEFINIERT IN
+============
-BEISPIELE:
+ /std/thing/language.c
- 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.
+ARGUMENTE
+=========
-SIEHE AUCH:
- SuggestArticle(), QueryPossPronoun(), /std/thing/language.c
- QueryOwn()
-----------------------------------------------------------------------------
+ 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/lfun/QueryProp b/doc/lfun/QueryProp
index ee752e0..71c4fdf 100644
--- a/doc/lfun/QueryProp
+++ b/doc/lfun/QueryProp
@@ -1,39 +1,63 @@
+
QueryProp()
-FUNKTION:
- mixed QueryProp(string name);
+***********
-DEFINIERT IN:
- /std/thing/properties.c
-ARGUMENTE:
- string name - abzufragende Property
+FUNKTION
+========
-BESCHREIBUNG:
- Der Datenwert der Property 'name' wird zurueckgegeben.
+ mixed QueryProp(string name);
- 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.)
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- Der Datenwert der Property.
- 0, falls diese nicht existiert.
+ /std/thing/properties.c
-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
+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/lfun/QueryProperties b/doc/lfun/QueryProperties
index aa740b5..6949e0f 100644
--- a/doc/lfun/QueryProperties
+++ b/doc/lfun/QueryProperties
@@ -1,30 +1,54 @@
+
QueryProperties()
-FUNKTION:
- mapping QueryProperties()
+*****************
-DEFINIERT IN:
- /std/thing/properties.c
-ARGUMENTE:
- keine
+FUNKTION
+========
-BESCHREIBUNG:
- Diese Funktion liefert ein Mapping mit allen fuer das Objekt
- definierten Properties zurueck.
+ mapping QueryProperties()
-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!
+DEFINIERT IN
+============
-SIEHE AUCH:
- Aehnliches: SetProp(L), QueryProp(L), Set(L), Query(L)
- Generell: SetProperties(L)
- Konzept: properties, /std/thing/properties.c
+ /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/lfun/QueryQuest b/doc/lfun/QueryQuest
index 295ad16..338ed77 100644
--- a/doc/lfun/QueryQuest
+++ b/doc/lfun/QueryQuest
@@ -1,34 +1,53 @@
+
QueryQuest()
+************
-FUNKTION:
- int QueryQuest(string questname)
-DEFINIERT IN:
- /std/player/quests.c
+FUNKTION
+========
-ARGUMENTE:
- questname
- Questname, wie er im Questmaster eingetragen wurde.
+ int QueryQuest(string questname)
-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.
+DEFINIERT IN
+============
- Wer sich da nicht sicher ist, kann mit dem Questtool
- (/obj/tools/questtool) nachsehen.
+ /std/player/quests.c
-SIEHE AUCH:
- /secure/questmaster.h, /obj/tools/questtool
- GiveQuest
-----------------------------------------------------------------------------
+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/lfun/QueryQuestTime b/doc/lfun/QueryQuestTime
index 2410d6a..9b93c8d 100644
--- a/doc/lfun/QueryQuestTime
+++ b/doc/lfun/QueryQuestTime
@@ -1,29 +1,48 @@
+
QueryQuestTime()
+****************
-FUNKTION:
- int QueryQuestTime(string questname)
-DEFINIERT IN:
- /std/player/quests.c
+FUNKTION
+========
-ARGUMENTE:
- questname
- Questname, wie er im Questmaster eingetragen wurde.
+ int QueryQuestTime(string questname)
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- GiveQuest(L), QueryQuest(L), ModifyQuestTime(L)
+ /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/lfun/QueryRealAttribute b/doc/lfun/QueryRealAttribute
index 7ee9f83..246008f 100644
--- a/doc/lfun/QueryRealAttribute
+++ b/doc/lfun/QueryRealAttribute
@@ -1,26 +1,47 @@
+
QueryRealAttribute()
-FUNKTION:
- int QueryRealAttribute(string attr)
+********************
-DEFINIERT IN:
- /std/living/attributes.c
-ARGUMENTE:
- attr - das interessierende Attribut
+FUNKTION
+========
-BESCHREIBUNG:
- Das reale Attribut (ohne Offsets) wird zurueckgegeben.
+ int QueryRealAttribute(string attr)
-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
+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/lfun/QuerySellValue b/doc/lfun/QuerySellValue
index 544cb29..4d5a518 100644
--- a/doc/lfun/QuerySellValue
+++ b/doc/lfun/QuerySellValue
@@ -1,43 +1,54 @@
-FUNKTION:
- varargs int QuerySellValue(object ob, object client);
+QuerySellValue()
+****************
-DEFINIERT IN:
- /std/trading_price.c
+FUNKTION
+========
-BESCHREIBUNG:
+ varargs int QuerySellValue(object ob, object client);
- 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.
+DEFINIERT IN
+============
-BEISPIEL:
+ /std/trading_price.c
- Ein Laden zahlt 10% ueber dem normalen Verkaufspreis:
- private int sell_factor = 110;
+BESCHREIBUNG
+============
- 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.
+ 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.
- // Basispreis ermitteln
- int preis = ::QuerySellValue(ob, client);
- // und den Bonus aufschlagen.
- preis = (sell_factor * preis)/100;
+ Ein Beispiel ist der Laden auf dem Kutter in Port Vain, der nur in
+ laengeren Intervallen mal zugaenglich ist.
- // Nicht mehr auszahlen, als das Objekt an sich wert ist.
- return min(preis, ob->QueryProp(P_VALUE));
- }
-----------------------------------------------------------------------------
+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/lfun/QuerySkill b/doc/lfun/QuerySkill
index 017b9f9..0978df1 100644
--- a/doc/lfun/QuerySkill
+++ b/doc/lfun/QuerySkill
@@ -1,35 +1,56 @@
+
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.
+FUNKTION
+========
- 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).
+ public varargs mapping QuerySkill(string sname, string gilde)
-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
+DEFINIERT IN
+============
-5. Okt 2011 Gloinson
\ No newline at end of file
+ /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/lfun/QuerySkillAbility b/doc/lfun/QuerySkillAbility
index 5cfd815..fd8666f 100644
--- a/doc/lfun/QuerySkillAbility
+++ b/doc/lfun/QuerySkillAbility
@@ -1,29 +1,47 @@
+
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).
+FUNKTION
+========
-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
+ 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/lfun/QuerySkillAttribute b/doc/lfun/QuerySkillAttribute
index d0b1bd1..1b3a71e 100644
--- a/doc/lfun/QuerySkillAttribute
+++ b/doc/lfun/QuerySkillAttribute
@@ -1,58 +1,87 @@
+
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]));
- }
+FUNKTION
+========
-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
+ 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/lfun/QuerySkillAttributeModifier b/doc/lfun/QuerySkillAttributeModifier
index 507c51b..055815e 100644
--- a/doc/lfun/QuerySkillAttributeModifier
+++ b/doc/lfun/QuerySkillAttributeModifier
@@ -1,90 +1,118 @@
+
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
+FUNKTION
+========
- <atrnames> string*
- Array von Skill-Attributen, welche durchsucht werden sollen.
+ public varargs mapping QuerySkillAttributeModifier(object caster,
+ string *atrnames)
-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.).
+DEFINIERT IN
+============
-BEMERKUNGEN:
+ /std/living/skill_attributes.c
-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
+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/lfun/QuerySkillBonus b/doc/lfun/QuerySkillBonus
index 1a4ef47..1cb82e8 100644
--- a/doc/lfun/QuerySkillBonus
+++ b/doc/lfun/QuerySkillBonus
@@ -1,65 +1,91 @@
+
QuerySkillBonus()
+*****************
-FUNKTION:
- int QuerySkillBonus(object caster, object target, mapping sinfo)
-DEFINIERT IN:
- beliebigen Objekten
+FUNKTION
+========
-ARGUMENTE:
- object caster
- der Benutzer eines Skills/Spells (Lebewesen)
- object target
- das Ziel eines Skills/Spells (beliebiges Objekt oder 0)
- mapping sinfo
- das Skillinfomapping
+ int QuerySkillBonus(object caster, object target, mapping sinfo)
-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%).
+DEFINIERT IN
+============
- 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.
+ beliebigen Objekten
-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;
- }
+ARGUMENTE
+=========
-SIEHE AUCH:
- gilden-doku
- <new_skills.h>
+ object caster
+ der Benutzer eines Skills/Spells (Lebewesen)
+ object target
+ das Ziel eines Skills/Spells (beliebiges Objekt oder 0)
+ mapping sinfo
+ das Skillinfomapping
-LETZTE AeNDERUNG:
+
+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/lfun/QueryStorageRoom b/doc/lfun/QueryStorageRoom
index b62e40d..4442237 100644
--- a/doc/lfun/QueryStorageRoom
+++ b/doc/lfun/QueryStorageRoom
@@ -1,21 +1,27 @@
-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
+
+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/lfun/QueryTimedAttrModifier b/doc/lfun/QueryTimedAttrModifier
index 1908608..4d858a8 100644
--- a/doc/lfun/QueryTimedAttrModifier
+++ b/doc/lfun/QueryTimedAttrModifier
@@ -1,42 +1,67 @@
+
QueryTimedAttrModifier()
-FUNKTION:
- mapping QueryTimedAttrModifier(string key)
+************************
-DEFINIERT IN:
- /std/living/attributes.c
-ARGUMENTE:
- key - aus P_TIMED_ATTR_MOD abzufragender Eintrag
+FUNKTION
+========
-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
+ 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/lfun/QueryTotalQP b/doc/lfun/QueryTotalQP
index cf15cc0..1471010 100644
--- a/doc/lfun/QueryTotalQP
+++ b/doc/lfun/QueryTotalQP
@@ -1,25 +1,43 @@
+
QueryTotalQP()
+**************
-FUNKTION:
- int QueryTotalQP()
-DEFINIERT IN:
- /secure/questmaster.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ int QueryTotalQP()
-RUECKGABEWERT:
- Abenteuerpunkte saemtlicher Quests
-BESCHREIBUNG:
- Diese Funktion liefert die Abenteuerpunkte der saemtlicher aktivierter
- Quests zurueck.
+DEFINIERT IN
+============
-SIEHE AUCH:
- GiveQuest, QueryQuest, /secure/questmaster.h, QueryGroupedKeys,
- QueryMaxQP, QueryOptQP
+ /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/lfun/QueryUser b/doc/lfun/QueryUser
index 129a0a5..ad1e4fa 100644
--- a/doc/lfun/QueryUser
+++ b/doc/lfun/QueryUser
@@ -1,50 +1,77 @@
+
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
+FUNKTION
+========
-ARGUMENTE:
- keine
+ public object QueryUser()
-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.
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- Das nutzende Lebewesen, falls es ermittelt werden konnte, sonst 0.
+ /std/npc/combat.c
+ /std/clothing/wear.c
+ /std/weapon/combat.c
+ alle Objekte, in denen es darueber hinaus noetig ist
-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
-----------------------------------------------------------------------------
+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/lfun/QueryValidObject b/doc/lfun/QueryValidObject
index 4622d65..649a0b2 100644
--- a/doc/lfun/QueryValidObject
+++ b/doc/lfun/QueryValidObject
@@ -1,47 +1,69 @@
+
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
-----------------------------------------------------------------------------
+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/lfun/ReceiveMsg b/doc/lfun/ReceiveMsg
index 6443bcd..cd1a34d 100644
--- a/doc/lfun/ReceiveMsg
+++ b/doc/lfun/ReceiveMsg
@@ -1,250 +1,278 @@
+
+ReceiveMsg()
+************
+
ReceiveMsg()
-public varargs int ReceiveMsg(string msg, int msg_typ, string msg_action,
- string msg_prefix, mixed origin)
+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()
+DEFINIERT IN
+============
-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.
+ /std/living/comm.c
+ /std/npc/comm.c
+ /std/player/comm.c
+ /std/room/items.c
- 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
+ARGUMENTE
+=========
- 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
+ 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()
-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
+BESCHREIBUNG
+============
-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);
+ 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.
- #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!",
+ 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) {
+ [...]
+ }
- #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);
+ return ret;
+ }
- #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
+ #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);
- // 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) {
- [...]
- }
+ #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);
- return ret;
- }
+ #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);
- #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);
+KONSTANTEN FUER PARAMETER
+=========================
- #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);
+ Saemtlich in "/sys/living/comm.h". Hier nicht notwendigerweise
+ immer aktuell oder vollstaendig.
- #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);
+ <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
- #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);
+ 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
-KONSTANTEN FUER PARAMETER:
- Saemtlich in "/sys/living/comm.h". Hier nicht notwendigerweise
- immer aktuell oder vollstaendig.
+ 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_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_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)
- 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()
+SIEHE AUCH
+==========
- <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)
+ 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/lfun/RegisterEvent b/doc/lfun/RegisterEvent
index 8bc5d8d..a664b3b 100644
--- a/doc/lfun/RegisterEvent
+++ b/doc/lfun/RegisterEvent
@@ -1,82 +1,113 @@
-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.
+RegisterEvent()
+***************
-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!
+FUNKTION
+========
-BEISPIELE:
- 1. Ein Objekt moechte ueber Spielertode informiert werden:
- EVENTD->RegisterEvent(EVT_LIB_PLAYER_DEATH, "spieler_ist_tot",
+ 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());
- 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()
+SIEHE AUCH
+==========
-----------------------------------------------------------------------------
+ events, eventd, UnregisterEvent(), TriggerEvent()
+
Last modified: 15.08.2007, Zesstra
diff --git a/doc/lfun/RegisterHelperNPC b/doc/lfun/RegisterHelperNPC
index 170e8b1..f8b6a2e 100644
--- a/doc/lfun/RegisterHelperNPC
+++ b/doc/lfun/RegisterHelperNPC
@@ -1,87 +1,114 @@
+
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.
+FUNKTION
+========
- int flags
- ver-oder-te Konstanten, die die Art des Helfer-NPC beschreiben (s.u.)
+ public int RegisterHelperNPC(object npc, int flags);
-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.
+DEFINIERT IN
+============
- 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.
+ /std/player/combat.c
+ /sys/living/combat.h
- 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.
+ARGUMENTE
+=========
- 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.
+ object npc
+ Objekt des helfenden NPC, der angemeldet werden soll.
-RUeCKGABEWERT:
- 1, wenn die Registrierung erfolgreich war.
- 0 sonst. In diesem Fall darf der NPC dem Spieler NICHT helfen, weder
- passiv (Schlagfaenger), noch aktiv.
+ int flags
+ ver-oder-te Konstanten, die die Art des Helfer-NPC beschreiben (s.u.)
-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...
- }
+BESCHREIBUNG
+============
- 2a. Ein exklusiver Nicht-Gilden-NPC
- if (spieler->RegisterHelperNPC(this_object(),
- MISC_HELPER|EXCLUSIVE_HELPER) == 1) {
- move(environment(spieler), M_GO);
- }
+ 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.
- 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.
- }
+ Die Flags sind eine der folgenden Konstanten oder eine beliebige durch
+ ver-oder-ung gebildete Kombination.
- 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);
- }
+ 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.
- 4. Die Registrierung ohne Klasse schlaegt fehl, z.B.:
- spieler->RegisterHelperNPC(this_object(), 0);
- spieler->RegisterHelperNPC(this_object(), EXCLUSIVE_HELPER);
+ Zusaetzlich zu den Klassen gibt es noch weitere Flags, die etwas ueber
+ den Helfer-NPC sagen:
-SIEHE AUCH:
- UnregisterHelperNPC()
- P_HELPER_NPC
+ + 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/lfun/RegisterHelperObject b/doc/lfun/RegisterHelperObject
index aa1cb66..af33a5c 100644
--- a/doc/lfun/RegisterHelperObject
+++ b/doc/lfun/RegisterHelperObject
@@ -1,113 +1,145 @@
-FUNKTION:
- int RegisterHelperObject(object helper, int type,
- string|closure callback);
+RegisterHelperObject()
+**********************
-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.
+FUNKTION
+========
-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.
+ int RegisterHelperObject(object helper, int type,
+ string|closure callback);
- 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.
+DEFINIERT IN
+============
-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)
+ /std/living/helpers.c
-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
+ARGUMENTE
+=========
- // 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");
+ 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");
}
-
- // 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);
+ 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;
+ }
- 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
+==========
-SIEHE AUCH:
- Funktionen: UnregisterHelperObject()
- Properties: P_HELPER_OBJECTS, P_AERIAL_HELPERS, P_AQUATIC_HELPERS
- Sonstiges: /sys/living/helpers.h
+ 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/lfun/RemoveAdjective b/doc/lfun/RemoveAdjective
index 48605dd..bd1796f 100644
--- a/doc/lfun/RemoveAdjective
+++ b/doc/lfun/RemoveAdjective
@@ -1,24 +1,43 @@
+
RemoveAdjective()
+*****************
-FUNKTION:
- void RemoveAdjective(string|string* adj);
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-ARGUMENTE:
- adj
- String oder Array von String mit den Adjektiven.
+ void RemoveAdjective(string|string* adj);
-BESCHREIBUNG:
- Falls einige der vorhandenen Adjektive nicht mehr verwendet werden
- sollen, koennen sie mit dieser Funktion entfernt werden.
-RUeCKGABEWERT:
- keiner
+DEFINIERT IN
+============
-SIEHE AUCH:
- AddAdjective(), RemoveId(), /std/thing/description.c
+ /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/lfun/RemoveClass b/doc/lfun/RemoveClass
index 3eeda6c..26b0b79 100644
--- a/doc/lfun/RemoveClass
+++ b/doc/lfun/RemoveClass
@@ -1,23 +1,38 @@
+
RemoveClass()
+*************
-FUNKTION:
- void RemoveClass(string|string* class);
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-ARGUMENTE:
- string/string* class - String oder Stringarray der Klasse(n)
+ void RemoveClass(string|string* class);
-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
+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/lfun/RemoveCmd b/doc/lfun/RemoveCmd
index 25941c6..6adffbf 100644
--- a/doc/lfun/RemoveCmd
+++ b/doc/lfun/RemoveCmd
@@ -1,60 +1,91 @@
+
+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
+FUNKTION
+========
-BESCHREIBUNG:
- Mit AddCmd() hinzugefuegte Kommandos koennen mit diesem Befehl wieder
- abgemeldet werden. Die entfernten Kommandos sind direkt nach dem
- RemoveCmd()-Aufruf nicht mehr ansprechbar.
+ varargs int RemoveCmd(mixed cmd, int norule, mixed id)
- Wird ein Regelstring angegeben, so wird die identische AddCmd-
- Regel entfernt.
-BEMERKUNGEN:
- Uebergibt man fuer com eine 0, so werden alle definierten Kommandos
- entfernt!
+DEFINIERT IN
+============
-RUECKGABEWERT:
- Anzahl der entfernten Kommandos.
+ /std/thing/commands.c
-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)
+ARGUMENTE
+=========
-SIEHE AUCH:
- AddCmd(L), AddCmd_bsp
- Sonstiges: replace_personal(E), enable_commands(E), init(E)
- Alternativen: AddAction(L), add_action(E)
+ 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/lfun/RemoveDefender b/doc/lfun/RemoveDefender
index aad46df..1dec97a 100644
--- a/doc/lfun/RemoveDefender
+++ b/doc/lfun/RemoveDefender
@@ -1,36 +1,52 @@
+
RemoveDefender()
+****************
-FUNKTION:
- void RemoveDefender(object friend);
-DEFINIERT IN:
- /std/living/combat.c
+FUNKTION
+========
-ARGUMENTE:
- friend
- Objekt (normal Lebewesen), welches zukuenftig nicht mehr ueber
- Angriffe informiert werden soll und diese auch nicht mehr abwehrt.
+ void RemoveDefender(object friend);
-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
+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/lfun/RemoveDetail b/doc/lfun/RemoveDetail
index f73af2a..48a0330 100644
--- a/doc/lfun/RemoveDetail
+++ b/doc/lfun/RemoveDetail
@@ -1,57 +1,80 @@
+
RemoveDetail()
+**************
-FUNKTION:
- void RemoveDetail(mixed *keys);
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-ARGUMENTE:
- keys
- String oder Array von Strings mit den zu entfernenden Details.
+ void RemoveDetail(mixed *keys);
-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;
- }
+DEFINIERT IN
+============
- int schliesseLuke(string str) {
- if(str!="luke" || !GetDetail("oeffnung"))
- return 0;
- RemoveDetail("oeffnung"); // Detail wieder entfernen
- return 1;
- }
+ /std/thing/description.c
-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()
+ARGUMENTE
+=========
-8. Juli 2011 Gloinson
\ No newline at end of file
+ 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/lfun/RemoveExit b/doc/lfun/RemoveExit
index edc61f2..6854229 100644
--- a/doc/lfun/RemoveExit
+++ b/doc/lfun/RemoveExit
@@ -1,28 +1,49 @@
+
RemoveExit()
-FUNKTION:
- void RemoveExit(string|string* cmd);
+************
-DEFINIERT IN:
- /std/room/exits
-ARGUMENTE:
- string/string* cmd
- Richtung(en), die entfernt werden sollen.
+FUNKTION
+========
-BESCHREIBUNG:
- Die in cmd angegebenen Ausgaenge werden wieder entfernt.
+ void RemoveExit(string|string* cmd);
- 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!
+DEFINIERT IN
+============
-SIEHE AUCH:
- AddExit(), AddSpecialExit(), GetExits()
- RemoveSpecialExit(),
- H_HOOK_EXIT_USE, P_EXITS, P_HIDE_EXITS, /std/room/exits.c
- ausgaenge
+ /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/lfun/RemoveExtraLook b/doc/lfun/RemoveExtraLook
index af929ea..0369992 100644
--- a/doc/lfun/RemoveExtraLook
+++ b/doc/lfun/RemoveExtraLook
@@ -1,39 +1,65 @@
+
+RemoveExtraLook()
+*****************
+
RemoveExtraLook()
-int RemoveExtraLook(string look);
-DEFINIERT IN:
+int RemoveExtraLook(string look);
+=================================
+
+
+DEFINIERT IN
+============
+
/std/living/description.c
-BESCHREIBUNG:
+
+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.
+ARGUMENTE
+=========
-BEMERKUNGEN:
- Beim Entfernen mit dieser Funktion wird die "Endemeldung" des entfernten
- Eintrages nicht ausgegeben.
+ - string look:
+ Schluesselwort, unter dem der Eintrag, den man entfernen moechte, von
+ AddExtraLook() registriert wurde.
-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:
+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/lfun/RemoveFixedObject b/doc/lfun/RemoveFixedObject
index 7616b2b..22179de 100644
--- a/doc/lfun/RemoveFixedObject
+++ b/doc/lfun/RemoveFixedObject
@@ -1,40 +1,62 @@
+
RemoveFixedObject()
+*******************
-FUNKTION:
- void RemoveFixedObject(string filename);
-DEFINIERT IN:
- /std/laden.c
+FUNKTION
+========
-ARGUMENTE:
- str
- Dateiname des Objektes, welches nicht mehr dauerhaft im Laden sein
- soll.
+ void RemoveFixedObject(string filename);
-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!
+DEFINIERT IN
+============
-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.
+ /std/laden.c
-SIEHE AUCH:
- AddFixedObject(), SetStorageRoom(), /std/store.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/lfun/RemoveFromMenu b/doc/lfun/RemoveFromMenu
index a8326af..fdcb916 100644
--- a/doc/lfun/RemoveFromMenu
+++ b/doc/lfun/RemoveFromMenu
@@ -1,32 +1,55 @@
+
RemoveFromMenu()
+****************
-FUNKTION:
- int RemoveFromMenu(mixed ids)
-DEFINIERT IN:
- /std/pub.c
+FUNKTION
+========
-ARGUMENTE:
- ids - string oder string*
- String oder Array von Strings, mit denen sich die Speise bzw.
- das Getraenk beim Bestellen ansprechen laesst.
+ int RemoveFromMenu(mixed ids)
-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)
+DEFINIERT IN
+============
-SIEHE AUCH:
- AddToMenu(), AddFood(), AddDrink(), /sys/pub.h
+ /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/lfun/RemoveFunc b/doc/lfun/RemoveFunc
index 054abe4..bf01ae9 100644
--- a/doc/lfun/RemoveFunc
+++ b/doc/lfun/RemoveFunc
@@ -1,87 +1,113 @@
+
RemoveFunc()
+************
-FUNKTION:
- int RemoveFunc(object ruest, int info, object user);
-DEFINIERT IN:
- eigenen Objekten (fuer /std/clothing/wear)
+FUNKTION
+========
-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.
+ int RemoveFunc(object ruest, int info, object user);
-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.
+DEFINIERT IN
+============
-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.
+ eigenen Objekten (fuer /std/clothing/wear)
-BEISPIELE:
- Ein Umhang, den man nur mit guter Einstellung wieder ausziehen kann:
- inherit "std/armour.c";
+ARGUMENTE
+=========
- #include <properties.h>
- #include <moving.h>
+ 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.
- create()
- {
- ::create();
- SetProp(P_ARMOUR_TYPE, AT_CLOAK);
- /* zig weitere SetProp's, um den Umhang zu konfigurieren */
+BESCHREIBUNG
+============
- /* RemoveFunc() ist im Umhang selbst zu finden */
- SetProp(P_REMOVE_FUNC, this_object());
- }
+ 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.
- 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
+ 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/lfun/RemoveId b/doc/lfun/RemoveId
index 85e7099..efd709d 100644
--- a/doc/lfun/RemoveId
+++ b/doc/lfun/RemoveId
@@ -1,26 +1,44 @@
+
RemoveId()
+**********
-FUNKTION:
- void RemoveId(string|string* ids);
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-ARGUMENTE:
- ids
- String oder Array von Strings mit den Bezeichnungen, die aus der
- Liste der IDs des Objektes entfernt werden sollen.
+ void RemoveId(string|string* ids);
-BESCHREIBUNG:
- Wenn ein Objekt sich nicht mehr mit gewissen Bezeichnern ansprechen
- lassen soll, kann man diese mit dieser Funktion entfernen.
-RUeCKGABEWERT:
- keiner
+DEFINIERT IN
+============
-SIEHE AUCH:
- AddId(), RemoveAdjective(), /std/thing/description.c
+ /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/lfun/RemoveInfo b/doc/lfun/RemoveInfo
index 5ced62c..75485c6 100644
--- a/doc/lfun/RemoveInfo
+++ b/doc/lfun/RemoveInfo
@@ -1,24 +1,45 @@
+
RemoveInfo()
-FUNKTION:
- void RemoveInfo(string key)
+************
-DEFINIERT IN:
- /std/npc/info.c
-ARGUMENTE:
- key zu loeschender Schluessel
+FUNKTION
+========
-BESCHREIBUNG:
- Loescht die Antwort zum entsprechenden Frageschluessel.
+ void RemoveInfo(string key)
-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
+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/lfun/RemoveItem b/doc/lfun/RemoveItem
index aa454f7..a21cdc2 100644
--- a/doc/lfun/RemoveItem
+++ b/doc/lfun/RemoveItem
@@ -1,41 +1,64 @@
+
RemoveItem()
+************
-FUNKTION:
- void RemoveItem(mixed file);
-DEFINIERT IN:
- /std/room/items.c
+FUNKTION
+========
-ARGUMENTE:
- file
- String oder Array von Strings mit dem Namen des zu entfernenden
- Objekts.
+ void RemoveItem(mixed file);
-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
+DEFINIERT IN
+============
-BEISPIELE:
- Ein muellschluckerfreier Laden laesst sich wie folgt erzeugen:
+ /std/room/items.c
- inherit "/std/laden";
- #include <properties.h>
- create()
- {
- ::create(); // Hier wird u.a. der Muellschlucker erzeugt
+ARGUMENTE
+=========
- RemoveItem("/obj/entsorg"); // und weg damit!
+ file
+ String oder Array von Strings mit dem Namen des zu entfernenden
+ Objekts.
- SetProp(...); // und die normale Beschreibung...
- }
-SIEHE AUCH:
- AddItem(), /std/room/items.c
+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/lfun/RemoveKnownPotion b/doc/lfun/RemoveKnownPotion
index 5b1418c..f7af610 100644
--- a/doc/lfun/RemoveKnownPotion
+++ b/doc/lfun/RemoveKnownPotion
@@ -1,25 +1,45 @@
+
RemoveKnownPotion()
+*******************
-FUNKTION:
- int RemoveKnownPotion(int nr)
-DEFINIERT IN:
- /std/player/potion.c
+FUNKTION
+========
-ARGUMENTE:
- int nr Nummer eines ZTs
+ int RemoveKnownPotion(int nr)
-BESCHREIBUNG:
- Entfernt einen bekannten ZT aus einen Spieler. Nur vom Orakel rufbar.
-RUeCKGABEWERT:
- 1 Erfolg
- -1 fehlende Berechtigung
- -2 Nummer nicht eingetragen
+DEFINIERT IN
+============
-SIEHE AUCH:
- Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
- Verwandt: FindPotion(), AddKnownPotion(), InList()
- Props: P_POTIONROOMS, P_KNOWN_POTIONROOMS
+ /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/lfun/RemovePluralId b/doc/lfun/RemovePluralId
index 0960e02..23f394a 100644
--- a/doc/lfun/RemovePluralId
+++ b/doc/lfun/RemovePluralId
@@ -1,28 +1,49 @@
+
RemovePluralId()
+****************
-FUNKTION:
- void RemovePluralId(mixed id);
-DEFINIERT IN:
- /std/unit.c
+FUNKTION
+========
-ARGUMENTE:
- id
- Identfikationsstring oder Array von Strings
+ void RemovePluralId(mixed id);
-BESCHREIBUNG:
- Es werden ein oder mehrere Bezeichner entfernt, mit denen sich
- mehrere Einheiten der Menge ansprechen lassen.
-RUECKGABEWERT:
- keiner
+DEFINIERT IN
+============
-BEISPIELE:
- siehe /items/money.c
+ /std/unit.c
-SIEHE AUCH:
- RemoveSingularId(), AddPluralId(), AddId(), id(), /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/lfun/RemovePursuer b/doc/lfun/RemovePursuer
index 8ba2358..cf8f0dc 100644
--- a/doc/lfun/RemovePursuer
+++ b/doc/lfun/RemovePursuer
@@ -1,26 +1,53 @@
+
+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
+========
-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.
+ void RemovePursuer(object pursuer)
-RUECKGABEWERT:
- keiner
-BEMERKUNG:
- keine
+ARGUMENTE
+=========
-BEISPIELE:
- find_player("jof")->RemovePursuer(find_player("kirk"))
- Danach wird Jof nicht mehr von Kirk verfolgt.
+ pursuer: Objekt, das aus der Verfolgerliste des Objektes, in dem
+ RemovePursuer aufgerufen wurde, ausgetragen werden soll.
-SIEHE AUCH:
- "AddPursuer", "PreventFollow"
+
+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/lfun/RemoveReadDetail b/doc/lfun/RemoveReadDetail
index f357954..495dfe3 100644
--- a/doc/lfun/RemoveReadDetail
+++ b/doc/lfun/RemoveReadDetail
@@ -1,31 +1,50 @@
+
RemoveReadDetail()
+******************
-FUNKTION:
- void RemoveReadDetail(string|string* keys);
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-ARGUMENTE:
- keys
- String oder Array von Strings mit den zu entfernenden Details.
+ void RemoveReadDetail(string|string* keys);
-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!
+DEFINIERT IN
+============
-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()
+ /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/lfun/RemoveResistanceModifier b/doc/lfun/RemoveResistanceModifier
index 0e630fb..ca14c74 100644
--- a/doc/lfun/RemoveResistanceModifier
+++ b/doc/lfun/RemoveResistanceModifier
@@ -1,37 +1,57 @@
+
RemoveResistanceModifier()
+**************************
-FUNKTION:
- varargs void RemoveResistanceModifier(string add);
-DEFINIERT IN:
- /std/living/combat.c
+FUNKTION
+========
-ARGUMENTE:
- string add:
- Ein eventueller Identifikator fuer einen gesetzten Modifikator.
+ varargs void RemoveResistanceModifier(string add);
-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();
- }
+DEFINIERT IN
+============
-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
+ /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/lfun/RemoveRoute b/doc/lfun/RemoveRoute
index e301719..61fb082 100644
--- a/doc/lfun/RemoveRoute
+++ b/doc/lfun/RemoveRoute
@@ -1,23 +1,42 @@
+
RemoveRoute()
+*************
-FUNKTION:
- void RemoveRoute();
-DEFINIERT IN:
- /std/transport.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ void RemoveRoute();
-BESCHREIBUNG:
- Der Transporter wird angehalten und der gesamte Fahrplan wird
- geloescht. Damit lassen sich zum Beispiel variable Routen konstruieren.
-RUeCKGABEWERT:
- keiner
+DEFINIERT IN
+============
-SIEHE AUCH:
- AddRoute(), AddMsg(), AddFun(), /std/transport.c
+ /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/lfun/RemoveSensitiveObject b/doc/lfun/RemoveSensitiveObject
index 5f6e0dc..0678e70 100644
--- a/doc/lfun/RemoveSensitiveObject
+++ b/doc/lfun/RemoveSensitiveObject
@@ -1,56 +1,79 @@
+
RemoveSensitiveObject()
-FUNKTION:
- void RemoveSensitiveObject(object ob)
+***********************
-DEFINIERT IN:
- /std/container/inventory.c
- generalizes /std/living/inventory.c
-ARGUMENTE:
- ob - zu entfernendes Objekt
+FUNKTION
+========
-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().
+ void RemoveSensitiveObject(object ob)
-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})}));
- ...
- }
+DEFINIERT IN
+============
- // 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;
- }
+ /std/container/inventory.c
+ generalizes /std/living/inventory.c
- - 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
+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/lfun/RemoveSingularId b/doc/lfun/RemoveSingularId
index 016999c..fcf0c3d 100644
--- a/doc/lfun/RemoveSingularId
+++ b/doc/lfun/RemoveSingularId
@@ -1,28 +1,49 @@
+
RemoveSingularId()
+******************
-FUNKTION:
- void RemoveSingularId(mixed id);
-DEFINIERT IN:
- /std/unit.c
+FUNKTION
+========
-ARGUMENTE:
- id
- Identifikationsstring oder Array von Strings
+ void RemoveSingularId(mixed id);
-BESCHREIBUNG:
- Es werden ein oder mehrere Bezeichner entfernt, mit denen sich eine
- einzelne Einheit ansprechen laesst.
-RUECKGABEWERT:
- keiner
+DEFINIERT IN
+============
-BEISPIELE:
- siehe /items/money.c
+ /std/unit.c
-SIEHE AUCH:
- AddSingularId(), RemovePluralId(), AddId(), id(), /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/lfun/RemoveSkillAttributeModifier b/doc/lfun/RemoveSkillAttributeModifier
index 71dfd10..5fa69b2 100644
--- a/doc/lfun/RemoveSkillAttributeModifier
+++ b/doc/lfun/RemoveSkillAttributeModifier
@@ -1,59 +1,83 @@
+
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)
+FUNKTION
+========
- <caster> object
- Objekt, dessen Modifikator wieder entfernt werden soll.
+ public int RemoveSkillAttributeModifier(object caster, string atrname)
-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.
+DEFINIERT IN
+============
-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.
- }
- }
+ /std/living/skill_attributes.c
- // 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
+
+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/lfun/RemoveSmells b/doc/lfun/RemoveSmells
index cc72207..b56fe27 100644
--- a/doc/lfun/RemoveSmells
+++ b/doc/lfun/RemoveSmells
@@ -1,38 +1,57 @@
+
RemoveSmells()
+**************
-FUNKTION:
- void RemoveSmells(string|string* keys);
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-ARGUMENTE:
- keys
- String oder Array von Strings mit den zu entfernenden Details.
+ void RemoveSmells(string|string* keys);
-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:
+DEFINIERT IN
+============
- AddSmells("rauch",* H U S T *\n");
- call_out(#'RemoveSmells, 100, "rauch");
+ /std/thing/description.c
-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()
+
+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/lfun/RemoveSounds b/doc/lfun/RemoveSounds
index 50d900a..4ef4263 100644
--- a/doc/lfun/RemoveSounds
+++ b/doc/lfun/RemoveSounds
@@ -1,46 +1,66 @@
+
RemoveSounds()
+**************
-FUNKTION:
- void RemoveSounds(string|string* keys);
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-ARGUMENTE:
- keys
- String oder Array von Strings mit den zu entfernenden Details.
+ void RemoveSounds(string|string* keys);
-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:
+DEFINIERT IN
+============
- 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;
- }
+ /std/thing/description.c
-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()
+
+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/lfun/RemoveSpecialDetail b/doc/lfun/RemoveSpecialDetail
index ebec4cb..96a7a39 100644
--- a/doc/lfun/RemoveSpecialDetail
+++ b/doc/lfun/RemoveSpecialDetail
@@ -1,37 +1,60 @@
-VERALTET: RemoveSpecialDetail()
-FUNKTION:
- void RemoveSpecialDetail(string|string* keys);
+RemoveSpecialDetail()
+*********************
-DEFINIERT IN:
- /std/thing/description.c
-ARGUMENTE:
- keys
- String oder Array von Strings mit den zu entfernenden Details.
+VERALTET RemoveSpecialDetail()
+==============================
-BESCHREIBUNG:
- Entfernt die in keys angegebenen Details aus der Liste der
- vorhandenen SpecialDetails.
- VERALTET: Bitte RemoveDetail() benutzen.
+FUNKTION
+========
-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.
+ void RemoveSpecialDetail(string|string* keys);
-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()
+
+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/lfun/RemoveSpecialExit b/doc/lfun/RemoveSpecialExit
index 69a18e4..ee2e8e8 100644
--- a/doc/lfun/RemoveSpecialExit
+++ b/doc/lfun/RemoveSpecialExit
@@ -1,29 +1,49 @@
+
RemoveSpecialExit()
-FUNKTION:
- void RemoveSpecialExit(string|string* cmd);
+*******************
-DEFINIERT IN:
- /std/room/exits
-ARGUMENTE:
- string/string* cmd
- Richtung(en), die entfernt werden sollen.
+FUNKTION
+========
-BESCHREIBUNG:
- Die in cmd angegebenen Ausgaenge werden wieder entfernt.
+ void RemoveSpecialExit(string|string* cmd);
- 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!
+DEFINIERT IN
+============
-SIEHE AUCH:
- AddExit(), AddSpecialExit(), AddGuardedExit(), GetExits()
- RemoveExit(),
- P_EXITS, P_HIDE_EXITS, /std/room/exits.c
- ausgaenge
+ /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/lfun/RemoveTouchDetail b/doc/lfun/RemoveTouchDetail
index 8b816a4..4f6ace3 100644
--- a/doc/lfun/RemoveTouchDetail
+++ b/doc/lfun/RemoveTouchDetail
@@ -1,54 +1,75 @@
+
RemoveTouchDetail()
+*******************
-FUNKTION:
- void RemoveTouchDetail(string|string* keys);
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-ARGUMENTE:
- keys
- String oder Array von Strings mit den zu entfernenden Details.
+ void RemoveTouchDetail(string|string* keys);
-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.
+DEFINIERT IN
+============
- int knopf();
- void knopf2();
+ /std/thing/description.c
- 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));
+ARGUMENTE
+=========
- 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");
- }
+ keys
+ String oder Array von Strings mit den zu entfernenden Details.
-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()
+
+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/lfun/ResizeRingBuffer b/doc/lfun/ResizeRingBuffer
index c5a6c08..17c3332 100644
--- a/doc/lfun/ResizeRingBuffer
+++ b/doc/lfun/ResizeRingBuffer
@@ -1,44 +1,66 @@
+
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)
+FUNKTION
+========
-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.
+ protected struct std_ringbuffer buf RingBufferPut(
+ struct std_ringbuffer buf,
+ int size);
-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})
+DEFINIERT IN
+============
-SIEHE AUCH:
- RingBufferGet(), RingBufferPut(), CreateRingBuffer()
+ /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/lfun/RingBufferGet b/doc/lfun/RingBufferGet
index 8d6b467..128807f 100644
--- a/doc/lfun/RingBufferGet
+++ b/doc/lfun/RingBufferGet
@@ -1,41 +1,63 @@
+
RingBufferGet()
+***************
-FUNKTION:
- protected mixed RingBufferGet(struct std_ringbuffer buf);
-DEFINIERT IN:
- /std/util/ringbuffer.c
- /sys/util/ringbuffer.h
+FUNKTION
+========
-ARGUMENTE:
- buf - Ringpuffer, welcher ausgeben werden soll
+ protected mixed RingBufferGet(struct std_ringbuffer buf);
-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.
+DEFINIERT IN
+============
-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})
+ /std/util/ringbuffer.c
+ /sys/util/ringbuffer.h
-SIEHE AUCH:
- CreateRingBuffer(), RingBufferPut(), ResizeRingBuffer()
+
+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/lfun/RingBufferPut b/doc/lfun/RingBufferPut
index 82a78bb..00c046c 100644
--- a/doc/lfun/RingBufferPut
+++ b/doc/lfun/RingBufferPut
@@ -1,30 +1,49 @@
+
RingBufferPut()
+***************
-FUNKTION:
- protected void RingBufferPut(struct std_ringbuffer buf, mixed val);
-DEFINIERT IN:
- /std/util/ringbuffer.c
- /sys/util/ringbuffer.h
+FUNKTION
+========
-ARGUMENTE:
- buf - Ringpuffer, in den <val> geschrieben werden soll
- val - neues Datum
+ protected void RingBufferPut(struct std_ringbuffer buf, mixed val);
-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);
+DEFINIERT IN
+============
-SIEHE AUCH:
- RingBufferGet(), CreateRingBuffer(), ResizeRingBuffer()
+ /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/lfun/SearchPath b/doc/lfun/SearchPath
index 035fdcb..040965e 100644
--- a/doc/lfun/SearchPath
+++ b/doc/lfun/SearchPath
@@ -1,58 +1,82 @@
-SearchPath
-FUNKTION:
- public int SearchPath(string from, string to, int para,
- closure callback)
+SearchPath()
+************
-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
+FUNKTION
+========
-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.
+ public int SearchPath(string from, string to, int para,
+ closure callback)
- 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.
+DEFINIERT IN
+============
-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
+ /p/daemon/pathd.c
+ <sys/path.d>
-BEMERKUNGEN:
+
+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.
@@ -64,7 +88,10 @@
Die Closure <callback> sollte nicht zuviele Ticks verbrauchen.
-BEISPIEL:
+
+BEISPIEL
+========
+
#include <pathd.h>
void suchergebnis(string from, string to, int para, int costs, string*
path, string* cmds) {
@@ -78,6 +105,4 @@
"/d/ebene/dancer/lucky/room/pova_la3",
0, #'suchergebnis);
-----------------------------------------------------------------------------
22.12.2015, Zesstra
-
diff --git a/doc/lfun/SelectEnemy b/doc/lfun/SelectEnemy
index 863e0c0..5a05eab 100644
--- a/doc/lfun/SelectEnemy
+++ b/doc/lfun/SelectEnemy
@@ -1,32 +1,51 @@
+
SelectEnemy()
+*************
-FUNKTION:
- varargs object SelectEnemy(object*here);
-DEFINIERT IN:
- /std/living/combat.c
+FUNKTION
+========
-ARGUMENTE:
- here
- Gegner, aus welchen ausgewaehlt werden soll (optional!)
+ varargs object SelectEnemy(object*here);
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- PresentEnemies(), QueryPreferedEnemy(), P_PREFERED_ENEMY,
- InsertEnemy(), StopHuntFor()
+ /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/lfun/SelectFarEnemy b/doc/lfun/SelectFarEnemy
index d574dcc..c390d42 100644
--- a/doc/lfun/SelectFarEnemy
+++ b/doc/lfun/SelectFarEnemy
@@ -1,45 +1,65 @@
SelectFarEnemy()
+****************
-FUNKTION:
- varargs object SelectFarEnemy(object *here, int min, int max,
- int forcefrom)
+FUNKTION
+========
-DEFINIERT IN:
- /std/living/team.c
+ varargs object SelectFarEnemy(object *here, int min, int max,
+ int forcefrom)
-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.
+DEFINIERT IN
+============
-RUECKGABEWERT:
- Der Auserwaehlte :-)
+ /std/living/team.c
-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
+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/lfun/SelectNearEnemy b/doc/lfun/SelectNearEnemy
index 998bee8..43ba033 100644
--- a/doc/lfun/SelectNearEnemy
+++ b/doc/lfun/SelectNearEnemy
@@ -1,49 +1,69 @@
SelectNearEnemy()
+*****************
-FUNKTION:
- varargs object SelectNearEnemy(object *here, int forcefrom)
+FUNKTION
+========
-DEFINIERT IN:
- /std/living/team.c
+ varargs object SelectNearEnemy(object *here, int forcefrom)
-ARGUMENTE:
- here - Rueckgabewert von PresentEnemies()
- forcefrom - Gegner MUSS aus uebergebenem Array ausgewaehlt werden
-BESCHREIBUNG:
- Waehlt einen im Nahkampf erreichbaren Feind aus
+DEFINIERT IN
+============
-RUECKGABEWERT:
- Der Auserwaehlte :-)
+ /std/living/team.c
-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
+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/lfun/Set b/doc/lfun/Set
index 42e6930..d654027 100644
--- a/doc/lfun/Set
+++ b/doc/lfun/Set
@@ -1,137 +1,174 @@
+
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.
+FUNKTION
+========
-BESCHREIBUNG:
- Eine der inneren Eigenschaften der Property 'name' wird veraendert.
- 'Type' ist dabei einer der in /sys/thing/properties.h definierten
- F_XXX - Werte:
+ public varargs mixed Set(string name, mixed Value, int Type, int extern);
- 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.
+DEFINIERT IN
+============
-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.
+ /std/thing/properties.c
+ /sys/thing/properties.h (Prototyp)
- 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);
+ARGUMENTE
+=========
- // 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.
+ 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.
- // 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);
+BESCHREIBUNG
+============
- // Permanenter Zugriffsschutz fuer eine Property:
- Set(P_XYZ, SECURED, F_MODE_AS);
+ Eine der inneren Eigenschaften der Property 'name' wird veraendert.
+ 'Type' ist dabei einer der in /sys/thing/properties.h definierten
+ F_XXX - Werte:
- ### Setzen einer SetMethod/QueryMethod ###
- // Setzen einer internen SetMethod
- mixed foo(mixed val);
- ...
- Set(P_XYZ, #'foo, F_SET_METHOD);
- ...
+ 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:
- // Setzen einer QueryMethod bei einem anderen Objekt
- mixed bar();
- ...
- other->Set(P_XYZ, #'bar, F_QUERY_METHOD);
- ...
+ SAVE
- // 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);
+ Property wird bei save_object() gespeichert
-SIEHE AUCH:
- Aehnliches: SetProp(L), QueryProp(L), Query(L)
- Generell: SetProperties(L), QueryProperties(L)
- Konzept: properties, /std/thing/properties.c
- Sonstiges: P_AUTOLOADOBJ
+ PROTECTED
-06. Jan 2008 Arathorn
+ 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/lfun/SetAttackChats b/doc/lfun/SetAttackChats
index 87203a1..90e8a66 100644
--- a/doc/lfun/SetAttackChats
+++ b/doc/lfun/SetAttackChats
@@ -1,68 +1,104 @@
+
SetAttackChats()
+****************
-FUNKTION:
- void SetAttackChats(int chance, mixed strs);
-DEFINIERT IN:
- /std/npc/chat.c
+FUNKTION
+========
-ARGUMENTE:
- chance
- Prozentuale Wahrscheinlichkeit einer Ausgabe
- strs
- Stringarray mit den Monsterchats
+ void SetAttackChats(int chance, mixed strs);
-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:
+DEFINIERT IN
+============
- 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
- }
+ /std/npc/chat.c
-SIEHE AUCH:
- P_ACHAT_CHANCE, SetChats(), /std/npc/chat.c, AddSpell()
-LETZTE AENDERUNG:
- Don, 27.12.2007, 16:35:00 von Arathorn
+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/lfun/SetAttr b/doc/lfun/SetAttr
index 8ed476f..fe5d97b 100644
--- a/doc/lfun/SetAttr
+++ b/doc/lfun/SetAttr
@@ -1,31 +1,55 @@
+
SetAttr()
-FUNKTION:
- public int SetAttr(string attr, int val)
+*********
-DEFINIERT IN:
- /std/living/attributes.c
-ARGUMENTE:
- attr - zu setzendes Attribut
- val - Wert
+FUNKTION
+========
-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.
+ public int SetAttr(string attr, int val)
-RUeCKGABEWERT:
- Tatsaechlich gesetzter Wert.
-BEMERKUNGEN:
- Wird von SetAttribute() und SetRealAttribute() aufgerufen.
+DEFINIERT IN
+============
-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
+ /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/lfun/SetAttribute b/doc/lfun/SetAttribute
index bab54f2..139fc99 100644
--- a/doc/lfun/SetAttribute
+++ b/doc/lfun/SetAttribute
@@ -1,28 +1,49 @@
+
SetAttribute()
-FUNKTION:
- int SetAttribute(string attr, int val)
+**************
-DEFINIERT IN:
- /std/living/attributes.c
-ARGUMENTE:
- attr - zu setzendes Attribut
- val - Wert
+FUNKTION
+========
-BESCHREIBUNG:
- Nimm val als Gesamtwert des Attributes, d.h. zieht etwaige Offsets vor
- Setzen ab. (QueryAttribute gibt dann also val zurueck)
+ int SetAttribute(string attr, int val)
-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
+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/lfun/SetBuyFact b/doc/lfun/SetBuyFact
index b5154c7..8994bd3 100644
--- a/doc/lfun/SetBuyFact
+++ b/doc/lfun/SetBuyFact
@@ -1,36 +1,58 @@
+
SetBuyFact()
+************
-FUNKTION:
- void SetBuyFact(int fact);
-DEFINIERT IN:
- /std/laden.c
+FUNKTION
+========
-ARGUMENTE:
- fact
- Der Einkaufspreismultiplikator.
+ void SetBuyFact(int fact);
-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.
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- keiner
+ /std/laden.c
-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
+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/lfun/SetChats b/doc/lfun/SetChats
index 3f425a8..70d312e 100644
--- a/doc/lfun/SetChats
+++ b/doc/lfun/SetChats
@@ -1,69 +1,94 @@
+
SetChats()
+**********
-FUNKTION:
- void SetChats(int chance,mixed strs);
-DEFINIERT IN:
- /std/npc/chat.c
+FUNKTION
+========
-ARGUMENTE:
- chance
- Prozentuale Wahrscheinlichkeit einer Ausgabe
- strs
- Stringarray mit den Monsterchats
+ void SetChats(int chance,mixed strs);
-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
+DEFINIERT IN
+============
-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";
- }
+ /std/npc/chat.c
-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()
+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/lfun/SetCoinsPerUnits b/doc/lfun/SetCoinsPerUnits
index 07e3879..0533275 100644
--- a/doc/lfun/SetCoinsPerUnits
+++ b/doc/lfun/SetCoinsPerUnits
@@ -1,38 +1,63 @@
+
SetCoinsPerUnits()
+******************
-FUNKTION:
- void SetCoinsPerUnits(int coins, int units);
-DEFINIERT IN:
- /std/unit.c
+FUNKTION
+========
-ARGUMENTE:
- coins
- Zahl der Muenzen
- units
- Zahl der Einheiten
+ void SetCoinsPerUnits(int coins, int units);
-BESCHREIBUNG:
- Es wird festgelegt, wieviel eine bestimmte Menge der Einheiten kostet.
- Eine einzelne Einheit kostet coins/units Muenzen.
-RUeCKGABEWERT:
- keiner
+DEFINIERT IN
+============
-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!
+ /std/unit.c
-BEISPIELE:
- Eine Einheit soll 3.5 Muenzen wert sein:
- /* 7 Muenzen / 2 Einheiten = 3.5 Muenzen / Einheit */
- SetCoinsPerUnits(7,2);
+ARGUMENTE
+=========
-SIEHE AUCH:
- QueryCoinsPerUnits(), SetGramsPerUnits(), QueryGramsPerUnits(),
- /std/unit.c
+ 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/lfun/SetDoorStatus b/doc/lfun/SetDoorStatus
index 1948637..c433c40 100644
--- a/doc/lfun/SetDoorStatus
+++ b/doc/lfun/SetDoorStatus
@@ -1,29 +1,49 @@
-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
+SetDoorStatus()
+***************
-SIEHE AUCH:
- NewDoor(), QueryDoorKey(), QueryDoorStatus(), P_DOOR_INFOS,
- /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
+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/lfun/SetEnemies b/doc/lfun/SetEnemies
index 6c79a56..2c92035 100644
--- a/doc/lfun/SetEnemies
+++ b/doc/lfun/SetEnemies
@@ -1,33 +1,53 @@
+
SetEnemies()
+************
-FUNKTION:
- mapping SetEnemies(object *myenemies);
-DEFINIERT IN:
- /std/living/combat.c
+FUNKTION
+========
-ARGUMENTE:
- myenemies
- Array: ({Gegnerarray, Zeitenarray})
+ mapping SetEnemies(object *myenemies);
-RUeCKGABEWERT:
- Internes Mapping mit bekannten Gegnern und Zeiten.
-BESCHREIBUNG:
- Normalerweise fuegt man einzelne Gegner mittels InsertEnemy() ein und
- loescht alte Feinde mittels StopHuntFor().
+DEFINIERT IN
+============
- Um jedoch mit einem Schlag viele Veraenderungen vorzunehmen, kann man
- die Funktion SetEnemies() nutzen.
+ /std/living/combat.c
- 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.
+ARGUMENTE
+=========
-SIEHE AUCH:
- InsertEnemy(), StopHuntFor(), SelectEnemy(), PresentEnemies()
+ 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/lfun/SetGramsPerUnits b/doc/lfun/SetGramsPerUnits
index fcbf9a4..66c1934 100644
--- a/doc/lfun/SetGramsPerUnits
+++ b/doc/lfun/SetGramsPerUnits
@@ -1,32 +1,54 @@
+
SetGramsPerUnits()
+******************
-FUNKTION:
- void SetGramsPerUnits(int grams, int units);
-DEFINIERT IN:
- /std/unit.c
+FUNKTION
+========
-ARGUMENTE:
- grams
- Gewicht in Gramm
- units
- Zahl der Einheiten
+ void SetGramsPerUnits(int grams, int units);
-BESCHREIBUNG:
- Es wird festgelegt, wieviel eine bestimmte Menge der Einheiten wiegt.
- Eine einzelne Einheit wiegt grams/units Gramm.
-RUeCKGABEWERT:
- keiner
+DEFINIERT IN
+============
-BEISPIELE:
- Vier Einheiten sollen 3 Gramm wiegen:
+ /std/unit.c
- SetGramsPerUnits(3,4);
-SIEHE AUCH:
- SetCoinsPerUnits(), QueryCoinsPerUnits(), QueryGramsPerUnits(),
- /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/lfun/SetProp b/doc/lfun/SetProp
index b2602fb..9664be8 100644
--- a/doc/lfun/SetProp
+++ b/doc/lfun/SetProp
@@ -1,47 +1,70 @@
+
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
+FUNKTION
+========
-BESCHREIBUNG:
- Der Datenwert der Property 'name' wird auf den Wert 'Value' gesetzt.
+ public mixed SetProp(string name, mixed Value);
- 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.)
+DEFINIERT IN
+============
-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.
+ /std/thing/properties.c
+ /sys/thing/properties.h (Prototyp)
- Wenn die Property nicht veraendert werden darf, wird -1 zurueckgegeben.
-BEISPIELE:
- // geben wir dem Zwerg eine Kurzbeschreibung
- SetProp(P_SHORT, "Ein kleiner Zwerg");
+ARGUMENTE
+=========
-SIEHE AUCH:
- Aehnliches: QueryProp(L), Set(L), Query(L)
- Generell: SetProperties(L), QueryProperties(L)
- Konzept: properties, /std/thing/properties.c
+ 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/lfun/SetProperties b/doc/lfun/SetProperties
index 4a1fa1d..a4ac72a 100644
--- a/doc/lfun/SetProperties
+++ b/doc/lfun/SetProperties
@@ -1,27 +1,48 @@
+
SetProperties()
-FUNKTION:
- void SetProperties(mapping props);
+***************
-DEFINIERT IN:
- /std/thing/properties.c
-ARGUMENTE:
- props - Mapping mit den Daten fuer alle Properties
+FUNKTION
+========
-BESCHREIBUNG:
- Diese Funktion setzt angegebene Properties auf einen Schlag.
- Mapping muss wie folgt aufgebaut sein:
- ([ name: wert; flags; set_method; query_method,
- name2: ... ]);
+ void SetProperties(mapping props);
-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
+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/lfun/SetRealAttribute b/doc/lfun/SetRealAttribute
index 68ea14c..fc72d9b 100644
--- a/doc/lfun/SetRealAttribute
+++ b/doc/lfun/SetRealAttribute
@@ -1,31 +1,55 @@
+
SetRealAttribute()
-FUNKTION:
- int SetRealAttribute(string attr, int val)
+******************
-DEFINIERT IN:
- /std/living/attributes.c
-ARGUMENTE:
- attr - zu setzendes Attribut
- val - Wert
+FUNKTION
+========
-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)
+ int SetRealAttribute(string attr, int val)
-RUeCKGABEWERT:
- Den gesetzten Wert.
-BEMERKUNGEN:
- Bitte nicht auf Spieler anwenden!
+DEFINIERT IN
+============
-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
+ /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/lfun/SetSpellFatigue b/doc/lfun/SetSpellFatigue
index c34627b..f2c5861 100644
--- a/doc/lfun/SetSpellFatigue
+++ b/doc/lfun/SetSpellFatigue
@@ -1,75 +1,99 @@
-SetSpellFatigue
-FUNKTION:
- public varargs int SetSpellFatigue(int duration, string key)
+SetSpellFatigue()
+*****************
-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.
+FUNKTION
+========
-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.
+ public varargs int SetSpellFatigue(int duration, string key)
- <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.
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- -1 Der Eintrag <key> ist noch nicht abgelaufen, es wurde _keine_
- neue Spruchermuedung/-Sperre gespeichert.
+ /std/living/skills.c
+ /std/player/skills.c
+ /sys/living/skills.h
- >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.)
+ARGUMENTE
+=========
-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.
+ int duration: Wie lang soll die Spruchermuedung andauern?
+ string key : Eindeutiger Name des Spruches, einer Gruppe von Spruechen
+ oder 0 fuer die globale Spruchermuedung.
-SIEHE AUCH:
- CheckSpellFatigue(L), DeleteSpellFatigue(L)
- P_NEXT_SPELL_TIME
- 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/lfun/SetStorageRoom b/doc/lfun/SetStorageRoom
index 4655a1e..f1d66a5 100644
--- a/doc/lfun/SetStorageRoom
+++ b/doc/lfun/SetStorageRoom
@@ -1,74 +1,108 @@
+
SetStorageRoom()
+****************
-FUNKTION:
- void SetStorageRoom(string store);
-DEFINIERT IN:
- /std/room/shop.c
+FUNKTION
+========
-ARGUMENTE:
- store
- Dateiname des Lagers, in dem die aufgekauften Objekte aufbewahrt
- werden.
+ void SetStorageRoom(string store);
-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.
+DEFINIERT IN
+============
-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");
- }
+ /std/room/shop.c
- 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.
+ARGUMENTE
+=========
-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.
+ store
+ Dateiname des Lagers, in dem die aufgekauften Objekte aufbewahrt
+ werden.
-SIEHE AUCH:
- Allgemeines: laden
- Funktionen: AddItem(L), AddFixedObject(L), RemoveFixedObject(L)
- Basisobjekte: /std/store.c
- Properties: P_MIN_STOCK, P_STORE_CONSUME
-----------------------------------------------------------------------------
+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/lfun/SetTimedAttrModifier b/doc/lfun/SetTimedAttrModifier
index 5804823..5ab39dd 100644
--- a/doc/lfun/SetTimedAttrModifier
+++ b/doc/lfun/SetTimedAttrModifier
@@ -1,92 +1,113 @@
+
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
+**********************
+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/lfun/ShowDoors b/doc/lfun/ShowDoors
index ecd36b0..c315632 100644
--- a/doc/lfun/ShowDoors
+++ b/doc/lfun/ShowDoors
@@ -1,23 +1,46 @@
+
ShowDoors()
+***********
-FUNKTION:
- void ShowDoors()
-ARGUMENTE:
- Keine.
+FUNKTION
+========
-BESCHREIBUNG:
- Zeigt alle Sehertor an, die der Seher (this_player()) schon kennt.
- Falls in seiner Umgebung ein Tor steht, so wird dieses eingeklammert.
+ void ShowDoors()
-RUECKGABEWERT:
- Keiner.
-BEMERKUNGEN:
- Diese Funktion wird von /d/seher/portale/sehertormaster definiert.
+ARGUMENTE
+=========
-BEISPIELE:
- /d/seher/portale/sehertormaster->ShowDoors()
+ Keine.
-SIEHE AUCH:
- DiscoverDoor, DoorIsKnown, Teleport, GetDoorsMapping
+
+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/lfun/ShowPropList b/doc/lfun/ShowPropList
index 64bc4cb..41599d7 100644
--- a/doc/lfun/ShowPropList
+++ b/doc/lfun/ShowPropList
@@ -1,49 +1,74 @@
+
ShowPropList()
+**************
-FUNKTION:
- void ShowPropList(string *props);
-DEFINIERT IN:
- /std/thing/util.c
+FUNKTION
+========
-ARGUMENTE:
- props
- Array von Strings mit den Namen der Properties, die ausgegeben
- werden sollen.
+ void ShowPropList(string *props);
-BESCHREIBUNG:
- Gibt die Inhalte der in props angegebenen Properties aus.
-RUeCKGABEWERT:
- keiner
+DEFINIERT IN
+============
-BEISPIELE:
- Sei test.c folgendes Programm:
+ /std/thing/util.c
- inherit "std/thing";
- inherit "std/thing/util";
- create() {
- ::create();
+ARGUMENTE
+=========
- SetProp(P_SHORT, "Kurz");
- SetProp(P_NAME, ({ "Name", "Namens", "Namen", "Namen" }));
- SetProp("me", this_object() );
- }
+ props
+ Array von Strings mit den Namen der Properties, die ausgegeben
+ werden sollen.
- 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)
+BESCHREIBUNG
+============
-BEMERKUNGEN:
- Mit dem Befehl xprops des MGtools lassen sich uebrigens saemtliche
- Properties eines Objekte auf einen Schlag ausgeben.
+ Gibt die Inhalte der in props angegebenen Properties aus.
-SIEHE AUCH:
- /std/ting/util.c
-----------------------------------------------------------------------------
+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/lfun/SkillResTransfer b/doc/lfun/SkillResTransfer
index 6983eea..128cea7 100644
--- a/doc/lfun/SkillResTransfer
+++ b/doc/lfun/SkillResTransfer
@@ -1,28 +1,48 @@
+
SkillResTransfer()
+******************
-FUNKTION:
- protected void SkillResTransfer(mapping from_M, mapping to_M)
-DEFINIERT IN:
- /std/living/skill_utils
+FUNKTION
+========
-ARGUMENTE:
- mapping from_M: Mapping mit zu kopierenden Werten
- mapping to_M: Zielmapping
+ protected void SkillResTransfer(mapping from_M, mapping to_M)
-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
+DEFINIERT IN
+============
-BEMERKUNGEN:
- * wird an mehreren Stellen, nicht nur der living/combat verwendet
+ /std/living/skill_utils
-SIEHE AUCH:
- P_TMP_ATTACK_MOD, UseSkill (Waffenfaehigkeiten)
+
+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/lfun/SpellAttack b/doc/lfun/SpellAttack
index 0e24fd9..ba00347 100644
--- a/doc/lfun/SpellAttack
+++ b/doc/lfun/SpellAttack
@@ -1,71 +1,97 @@
+
SpellAttack()
+*************
-FUNKTION:
- void SpellAttack(object enemy)
-ARGUMENTE:
- enemy: Der Feind.
+FUNKTION
+========
-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.
+ void SpellAttack(object enemy)
- 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.
+ARGUMENTE
+=========
-BEMERKUNG:
- Die AttackChats, die mittels SetAttackChats gesetzt werden
- koennen, macht im Grunde nichts anderes, aber Chats sind halt
- keine Angriffe. :-)
+ enemy: Der Feind.
-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;
- }
- }
+BESCHREIBUNG
+============
- 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
- }
+ 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.
-SIEHE AUCH:
- "Attack", "SetAttackChats", /std/npc/combat.c
+ 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.
-LETZTE AENDERUNG:
- Don, 27.02.2003, 12:50:00 von Hirudo
+
+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/lfun/SpellDefend b/doc/lfun/SpellDefend
index 79537d5..22b038c 100644
--- a/doc/lfun/SpellDefend
+++ b/doc/lfun/SpellDefend
@@ -1,43 +1,71 @@
+
SpellDefend()
-FUNKTION:
- public int SpellDefend(object caster,mapping sinfo);
+*************
-DEFINIERT IN:
- /std/living/combat.c
-ARGUMENTE:
- object caster - Gegner
- mapping sinfo - Zusatzinformationen zum Spell
+FUNKTION
+========
-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.
+ public int SpellDefend(object caster,mapping sinfo);
-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!
+DEFINIERT IN
+============
- Bitte bei NPCs nicht pauschal 100% / 10000 zurueckgeben. Danke.
+ /std/living/combat.c
-SIEHE AUCH:
- Verwandt: P_MAGIC_RESISTANCE_OFFSET
- Aehnlich: P_NOMAGIC
- Generell: TryGlobalAttackSpell, /std/spellbook.c
- Sonstiges: UseSkill, SK_SPELL_DEFEND
+
+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/lfun/SpellInform b/doc/lfun/SpellInform
index 369b201..ce8fdbd 100644
--- a/doc/lfun/SpellInform
+++ b/doc/lfun/SpellInform
@@ -1,31 +1,51 @@
-SpellInform
-FUNKTION:
- void SpellInform(caster,spell,sinfo);
+SpellInform()
+*************
-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
+FUNKTION
+========
-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.
+ void SpellInform(caster,spell,sinfo);
-RUeCKGABEWERT:
- keiner
-SIEHE AUCH:
-
-----------------------------------------------------------------------------
+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/lfun/Start b/doc/lfun/Start
index 89f63ef..e0b1070 100644
--- a/doc/lfun/Start
+++ b/doc/lfun/Start
@@ -1,25 +1,44 @@
+
Start()
+*******
-FUNKTION:
- varargs void Start(int pos);
-DEFINIERT IN:
- /std/transport.c
+FUNKTION
+========
-ARGUMENTE:
- pos
- Fahrplanstation, an der begonnen werden soll.
+ varargs void Start(int pos);
-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
+DEFINIERT IN
+============
-SIEHE AUCH:
- Halt(), /std/transport.c
+ /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/lfun/StopHuntFor b/doc/lfun/StopHuntFor
index 738b920..e09d9fa 100644
--- a/doc/lfun/StopHuntFor
+++ b/doc/lfun/StopHuntFor
@@ -1,52 +1,77 @@
+
StopHuntFor()
+*************
-FUNKTION:
- varargs int StopHuntFor(object arg,int silent);
-DEFINIERT IN:
- /std/living/combat.c
+FUNKTION
+========
-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.
+ varargs int StopHuntFor(object arg,int silent);
-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.
+DEFINIERT IN
+============
-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.
+ /std/living/combat.c
-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()
+ARGUMENTE
+=========
-----------------------------------------------------------------------------
-16.03.2008, Zesstra
+ 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/lfun/StopHuntText b/doc/lfun/StopHuntText
index 1ca8cfb..fca271b 100644
--- a/doc/lfun/StopHuntText
+++ b/doc/lfun/StopHuntText
@@ -1,58 +1,77 @@
+
StopHuntText()
+**************
-FUNKTION:
- void StopHuntText(object arg);
-DEFINIERT IN:
- /std/living/combat.c
+FUNKTION
+========
-ARGUMENTE:
- arg
- Der Gegner, welcher nicht mehr bekaempft wird.
+ void StopHuntText(object arg);
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- StopHuntFor(), SelectEnemy(), QueryEnemies(), IsEnemy()
+ /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/lfun/SuggestArticle b/doc/lfun/SuggestArticle
index 7a4ba5c..31c2047 100644
--- a/doc/lfun/SuggestArticle
+++ b/doc/lfun/SuggestArticle
@@ -1,35 +1,57 @@
+
SuggestArticle()
+****************
-FUNKTION:
- varargs int SuggestArticle(string name);
-DEFINIERT IN:
- /std/thing/language.c
+FUNKTION
+========
-ARGUMENTE:
- name
- Der Name zur Entscheidungshilfe.
+ varargs int SuggestArticle(string name);
-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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Der Vergleich erfolgt mittels der Property P_NAME. Um Erfolg zu haben,
- sollte man diese Funktion daher in der Form
+ /std/thing/language.c
- SuggestArticle(QueryProp(P_NAME))
- aufrufen.
+ARGUMENTE
+=========
-SIEHE AUCH:
- QueryArticle(), name(), /std/thing/language.c
+ 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/lfun/SwapRows b/doc/lfun/SwapRows
index 7d5d928..aa18364 100644
--- a/doc/lfun/SwapRows
+++ b/doc/lfun/SwapRows
@@ -1,40 +1,60 @@
SwapRows()
+**********
-FUNKTION:
- int SwapRows( object ob1, object ob2 )
+FUNKTION
+========
-DEFINIERT IN:
- /std/living/team.c
+ int SwapRows( object ob1, object ob2 )
-ARGUMENTE:
- ob1, ob2 - Spieler, die die Reihen tauschen sollen.
-BESCHREIBUNG:
- Die angegebenen Spieler tauschen die Reihen.
+DEFINIERT IN
+============
-RUECKGABEWERT:
- 1 bei erfolgreichem Tausch, 0 sonst.
+ /std/living/team.c
-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
+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/lfun/TakeFlaw b/doc/lfun/TakeFlaw
index 7bfd03a..40d99a2 100644
--- a/doc/lfun/TakeFlaw
+++ b/doc/lfun/TakeFlaw
@@ -1,75 +1,100 @@
+
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
+FUNKTION
+========
-ARGUMENTE:
- keine
+ varargs void TakeFlaw(object enemy); (Waffen)
+ varargs void TakeFlaw(mixed dam_types,mapping einfos) (Ruestungen)
-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.
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- keiner
+ /std/armour/combat.c,
+ /std/weapon/combat.c
-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:
+ARGUMENTE
+=========
- inherit "std/weapon";
+ keine
- #include <properties.h>
- #include <combat.h>
- create()
- {
- /* Das Uebliche... */
+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);
}
+ }
- TakeFlaw()
- {
- int flaw;
+ Dieses einfache Beispiel haette natuerlich auch ueber ein
+ SetProp(P_QUALITY,20); im create() realisiert werden koennen.
- /* erst mal den Zaehler erhoehen... */
- ::TakeFlaw();
- /* jetzt den aktuellen Zaehlerstand abfragen */
- flaw = QueryFlaw()[0];
+SIEHE AUCH
+==========
- /* 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);
- }
- }
+ QueryFlaw(), Damage(), DefendInfo, P_QUIALITY, /std/armour/combat.c,
+ /std/weapon/combat.c
- 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/lfun/TeamFlee b/doc/lfun/TeamFlee
index fb317a0..216fbbf 100644
--- a/doc/lfun/TeamFlee
+++ b/doc/lfun/TeamFlee
@@ -1,40 +1,60 @@
TeamFlee()
+**********
-FUNKTION:
- int TeamFlee()
+FUNKTION
+========
-DEFINIERT IN:
- /std/living/team.c
+ int TeamFlee()
-ARGUMENTE:
- keine
-BESCHREIBUNG:
- Spieler wird zur Flucht in hintere Reihe veranlasst, falls er dies
- eingestellt hat.
+DEFINIERT IN
+============
-RUECKGABEWERT:
- 1, falls der Spieler in eine hintere Reihe fliehen wollte und nach
- dem Versuch nicht mehr in der ersten Reihe steht, sonst 0.
+ /std/living/team.c
-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
+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/lfun/TeamMembers b/doc/lfun/TeamMembers
index 28ca93b..5971bfb 100644
--- a/doc/lfun/TeamMembers
+++ b/doc/lfun/TeamMembers
@@ -1,38 +1,58 @@
TeamMembers()
+*************
-FUNKTION:
- object *TeamMembers()
+FUNKTION
+========
-DEFINIERT IN:
- /std/living/team.c
+ object *TeamMembers()
-ARGUMENTE:
- keine
-BESCHREIBUNG:
- Liefert Teammitglieder des Teams des Spielers.
+DEFINIERT IN
+============
-RUECKGABEWERT:
- Array mit ALLEN Teammitgliedern.
+ /std/living/team.c
-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
+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/lfun/TeamPrefix b/doc/lfun/TeamPrefix
index efbebb7..2cf1582 100644
--- a/doc/lfun/TeamPrefix
+++ b/doc/lfun/TeamPrefix
@@ -1,37 +1,56 @@
TeamPrefix()
+************
-FUNKTION:
- string TeamPrefix()
+FUNKTION
+========
-DEFINIERT IN:
- /std/living/team.c
+ string TeamPrefix()
-ARGUMENTE:
- keine
-BESCHREIBUNG:
- Ergibt Team-Prefix eines Spielers.
+DEFINIERT IN
+============
-RUECKGABEWERT:
- "[Team Teamname] ", falls der Spieler in einem Team ist,
- "" sonst.
+ /std/living/team.c
-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
+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/lfun/Teleport b/doc/lfun/Teleport
index b902d07..ddddb89 100644
--- a/doc/lfun/Teleport
+++ b/doc/lfun/Teleport
@@ -1,28 +1,51 @@
+
Teleport()
+**********
-FUNKTION:
- int Teleport(string ziel)
-ARGUMENTE:
- ziel: Nummer des Sehertors, zu dem teleportiert werden soll.
+FUNKTION
+========
-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.
+ int Teleport(string ziel)
-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.
+ARGUMENTE
+=========
-BEISPIELE:
- /d/seher/portale/sehertormaster->Teleport(1)
+ ziel: Nummer des Sehertors, zu dem teleportiert werden soll.
-SIEHE AUCH:
- DiscoverDoor, DoorIsKnown, ShowDoors, GetDoorsMapping
+
+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/lfun/TestIgnore b/doc/lfun/TestIgnore
index 3e664c0..d1d2b95 100644
--- a/doc/lfun/TestIgnore
+++ b/doc/lfun/TestIgnore
@@ -1,66 +1,88 @@
+
TestIgnore()
+************
-FUNKTION:
- public int TestIgnore(string|string* arg)
-DEFINIERT IN:
- /std/player/comm.c
+FUNKTION
+========
-ARGUMENTE:
- arg
- String oder Array von Strings, die getestet werden sollen,
- Format jeweils: [spieler].aktion[.qualifizierer]
+ public int TestIgnore(string|string* arg)
-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?
+DEFINIERT IN
+============
- 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.
+ /std/player/comm.c
-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");
+ARGUMENTE
+=========
- // 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));
+ arg
+ String oder Array von Strings, die getestet werden sollen,
+ Format jeweils: [spieler].aktion[.qualifizierer]
-SIEHE AUCH:
- P_IGNORE, AddIgnore, RemoveIgnore, TestIgnoreSimple, /std/player/comm.c
+
+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/lfun/TestIgnoreSimple b/doc/lfun/TestIgnoreSimple
index 542632e..c0ec76e 100644
--- a/doc/lfun/TestIgnoreSimple
+++ b/doc/lfun/TestIgnoreSimple
@@ -1,55 +1,77 @@
+
TestIgnoreSimple()
+******************
-FUNKTION:
- public int TestIgnoreSimple(string *arg)
-DEFINIERT IN:
- /std/player/comm.c
+FUNKTION
+========
-ARGUMENTE:
- arg
- Liste von Strings, die getestet werden sollen
+ public int TestIgnoreSimple(string *arg)
-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.
+DEFINIERT IN
+============
-BEISPIEL:
- if (!this_player()->TestIgnoreSimple(({"andy"})))
- tell_object(this_player(), "Andy teilt Dir mit: Hallo!\n");
+ /std/player/comm.c
- // 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));
+ARGUMENTE
+=========
-SIEHE AUCH:
- P_IGNORE, AddIgnore, RemoveIgnore, TestIgnore, /std/player/comm.c
+ 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/lfun/TestLimitViolation b/doc/lfun/TestLimitViolation
index 9344299..df9f7b2 100644
--- a/doc/lfun/TestLimitViolation
+++ b/doc/lfun/TestLimitViolation
@@ -1,21 +1,39 @@
+
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
+FUNKTION
+========
-13.Jun.2004, Muadib
\ No newline at end of file
+ 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/lfun/TriggerEvent b/doc/lfun/TriggerEvent
index 7b0089f..44dd2e4 100644
--- a/doc/lfun/TriggerEvent
+++ b/doc/lfun/TriggerEvent
@@ -1,59 +1,87 @@
-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:
+TriggerEvent()
+**************
-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).
+FUNKTION
+========
-SIEHE AUCH:
- events, eventd, UnregisterEvent(), RegisterEvent()
+ 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/lfun/UnregisterEvent b/doc/lfun/UnregisterEvent
index 0de361a..6d9bfb7 100644
--- a/doc/lfun/UnregisterEvent
+++ b/doc/lfun/UnregisterEvent
@@ -1,49 +1,79 @@
-FUNKTION:
- int UnregisterEvent(string eid, object listener);
+UnregisterEvent()
+*****************
-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.
+FUNKTION
+========
-BESCHREIBUNG:
- Das Objekt 'listener' wird als Lauscher dieses Events ausgetragen. Ab
- diesem Moment wird es bei Events vom Typ 'eid' nicht mehr informiert.
+ int UnregisterEvent(string eid, object listener);
- 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.
+DEFINIERT IN
+============
-BEISPIELE:
- 1. Ein Objekt moechte nicht mehr ueber Spielertode informiert werden:
- EVENTD->UnregisterEvent(EVT_LIB_PLAYER_DEATH, this_object());
+ /p/daemon/eventd.c
- 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()
+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/lfun/UnregisterHelperNPC b/doc/lfun/UnregisterHelperNPC
index de384fd..79c18f6 100644
--- a/doc/lfun/UnregisterHelperNPC
+++ b/doc/lfun/UnregisterHelperNPC
@@ -1,45 +1,72 @@
+
UnregisterHelperNPC()
-FUNKTION:
- public int UnregisterHelperNPC(object npc);
+*********************
-DEFINIERT IN:
- /std/player/combat.c
-ARGUMENTE:
- object npc
- Objekt des helfenden NPC, der abgemeldet werden soll.
+FUNKTION
+========
-BESCHREIBUNG:
- Mit dieser Funktion wird ein einem Spieler helfender NPC im Spieler
- wieder abgemeldet, wenn dieser dem Spieler ab jetzt nicht mehr hilft.
+ public int UnregisterHelperNPC(object npc);
- 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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Diese Funktion setzt bei der Erfolg die Property P_HELPER_NPC in <npc>
- auf 0.
+ /std/player/combat.c
-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
+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/lfun/UnregisterHelperObject b/doc/lfun/UnregisterHelperObject
index eefd84e..d6242c9 100644
--- a/doc/lfun/UnregisterHelperObject
+++ b/doc/lfun/UnregisterHelperObject
@@ -1,47 +1,71 @@
-FUNKTION:
- int UnregisterHelperObject(object helper, int type);
-DEFINIERT IN:
- /std/living/helpers.c
+UnregisterHelperObject()
+************************
-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.
+FUNKTION
+========
-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)
+ int UnregisterHelperObject(object helper, int type);
-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();
- }
+DEFINIERT IN
+============
-SIEHE AUCH:
- Funktionen: RegisterHelperObject()
- Properties: P_HELPER_OBJECTS, P_AERIAL_HELPERS, P_AQUATIC_HELPERS
- Sonstiges: /sys/living/helpers.h
+ /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/lfun/Unwear b/doc/lfun/Unwear
index 624c7fc..0ef0a2a 100644
--- a/doc/lfun/Unwear
+++ b/doc/lfun/Unwear
@@ -1,38 +1,65 @@
+
Unwear()
-FUNKTION:
- public int Unwear(object ob)
+********
-DEFINIERT IN:
- /std/living/clothing.c
-ARGUMENTE:
- object ob
- Die Ruestung oder Kleidung, die ausgezogen wird.
+FUNKTION
+========
-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.
+ public int Unwear(object ob)
- 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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
- besten auch dann nicht.
+ /std/living/clothing.c
-SIEHE AUCH:
- Wear(), WearArmour(), WearClothing(), UnwearArmour(), UnwearClothing()
- P_CLOTHING, P_ARMOURS
- FilterClothing(), FilterArmours()
-ZULETZT GEAeNDERT:
+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/lfun/UnwearArmour b/doc/lfun/UnwearArmour
index 86b55da..b3c7d77 100644
--- a/doc/lfun/UnwearArmour
+++ b/doc/lfun/UnwearArmour
@@ -1,38 +1,65 @@
+
UnwearArmour()
-FUNKTION:
- public int UnwearArmour(object ob)
+**************
-DEFINIERT IN:
- /std/living/clothing.c
-ARGUMENTE:
- object ob
- Die Ruestung, die ausgezogen wird.
+FUNKTION
+========
-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.
+ public int UnwearArmour(object ob)
- 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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
- besten auch dann nicht.
+ /std/living/clothing.c
-SIEHE AUCH:
- Wear(), WearArmour(), WearClothing(), Unwear(), UnwearClothing()
- P_CLOTHING, P_ARMOURS
- FilterClothing(), FilterArmours()
-ZULETZT GEAeNDERT:
+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/lfun/UnwearClothing b/doc/lfun/UnwearClothing
index 0556654..fe0372b 100644
--- a/doc/lfun/UnwearClothing
+++ b/doc/lfun/UnwearClothing
@@ -1,38 +1,65 @@
+
UnwearClothing()
-FUNKTION:
- public int UnwearClothing(object ob)
+****************
-DEFINIERT IN:
- /std/living/clothing.c
-ARGUMENTE:
- object ob
- Das Kleidungsstuck, das ausgezogen wird.
+FUNKTION
+========
-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.
+ public int UnwearClothing(object ob)
- 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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
- besten auch dann nicht.
+ /std/living/clothing.c
-SIEHE AUCH:
- Wear(), WearArmour(), WearClothing(), Unwear(), UnwearArmour()
- P_CLOTHING, P_ARMOURS
- FilterClothing(), FilterArmours()
-ZULETZT GEAeNDERT:
+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/lfun/UnwieldFunc b/doc/lfun/UnwieldFunc
index 9e4929c..0301182 100644
--- a/doc/lfun/UnwieldFunc
+++ b/doc/lfun/UnwieldFunc
@@ -1,52 +1,74 @@
+
UnwieldFunc()
+*************
-FUNKTION:
- int UnwieldFunc(object weapon, int info, object user);
-DEFINIERT IN:
- eigenen Objekten, fuer /std/weapon/combat.c
+FUNKTION
+========
-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.
+ int UnwieldFunc(object weapon, int info, object user);
-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.
+DEFINIERT IN
+============
-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.
+ 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
+==========
-----------------------------------------------------------------------------
+ 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/lfun/UpdateAttributes b/doc/lfun/UpdateAttributes
index ef5a24f..cdebaa7 100644
--- a/doc/lfun/UpdateAttributes
+++ b/doc/lfun/UpdateAttributes
@@ -1,32 +1,52 @@
+
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.
+FUNKTION
+========
-BEMERKUNGEN:
- Sollte nach Einbringen neuer Modifikatorobjekte am Living gerufen
- werden.
+ void UpdateAttributes()
-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
+
+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/lfun/UpdateResistanceStrengths b/doc/lfun/UpdateResistanceStrengths
index 48747b3..8ae9198 100644
--- a/doc/lfun/UpdateResistanceStrengths
+++ b/doc/lfun/UpdateResistanceStrengths
@@ -1,26 +1,43 @@
+
UpdateResistanceStrengths()
+***************************
-FUNKTION:
- public void UpdateResistanceStrengths()
-DEFINIERT IN:
- /std/living/combat.c
+FUNKTION
+========
-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.
+ public void UpdateResistanceStrengths()
-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
+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/lfun/UseHands b/doc/lfun/UseHands
index a4fbc8d..d11723c 100644
--- a/doc/lfun/UseHands
+++ b/doc/lfun/UseHands
@@ -1,37 +1,61 @@
-UseHands
-FUNKTION:
- public varargs int UseHands(object ob, int num)
-DEFINIERT IN:
- /std/living/combat.c
+UseHands()
+**********
-ARGUMENTE:
- ob - das Objekt, das die Haende belegen soll
- num - die Anzahl der zu belegenden Haende
-RUECKGABEWERT:
- 1, fuer Erfolg
- 0, sonst
+FUNKTION
+========
-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.
+ public varargs int UseHands(object ob, int num)
-BEISPIELE:
- > halte seil fest
- ...
- this_player()->UseHands(this_object(),2);
- ...
- > lasse seil los
- ...
- this_player()->FreeHands(this_object());
- ...
+DEFINIERT IN
+============
-SIEHE AUCH:
- P_HANDS, P_HANDS_USED_BY
- P_MAX_HANDS, P_USED_HANDS, P_FREE_HANDS
- FreeHands
+ /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/lfun/UseSkill b/doc/lfun/UseSkill
index 3b12bd8..4f3398d 100644
--- a/doc/lfun/UseSkill
+++ b/doc/lfun/UseSkill
@@ -1,48 +1,74 @@
+
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)
+FUNKTION
+========
-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.
+ public varargs mixed UseSkill(string skill, mapping args)
-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
\ No newline at end of file
+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/lfun/UseSpell b/doc/lfun/UseSpell
index ddf1c4d..b5cfbf7 100644
--- a/doc/lfun/UseSpell
+++ b/doc/lfun/UseSpell
@@ -1,77 +1,105 @@
+
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
+FUNKTION
+========
-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).
+ public varargs int UseSpell(string str, string spell)
- 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).
+DEFINIERT IN
+============
- 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.
+ /std/living/skills.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.
+ARGUMENTE
+=========
-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
+ string str Spell-Optionen
+ string spell optionaler Spellname
-5. Okt 2011 Gloinson
\ No newline at end of file
+
+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/lfun/Validate b/doc/lfun/Validate
index 10f4791..ddfceef 100644
--- a/doc/lfun/Validate
+++ b/doc/lfun/Validate
@@ -1,36 +1,60 @@
-Validate()
-FUNKTION:
+Validate()
+**********
+
+
+FUNKTION
+========
+
string Validate(string oname);
-DEFINIERT IN:
+
+DEFINIERT IN
+============
+
/std/virtual/v_compiler.c
-ARGUMENTE:
- oname
- Objektname, der geprueft werden soll
-RUeCKGABEWERT:
-
-BESCHREIBUNG:
+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
+ 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:
+
+BEMERKUNGEN
+===========
+
Am besten ruft man in seinem Validate() das ::Validate(), was einem die
Arbeit abnimmt, ein .c am Ende zu entfernen.
-BEISPIEL:
+
+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")
@@ -38,10 +62,13 @@
return oname;
}
-SIEHE AUCH:
- virtual_compiler
- CustomizeObject(), Validate(), NoParaObjects(),
- P_COMPILER_PATH, P_PARA
- /std/virtual/v_compiler.c
-----------------------------------------------------------------------------
+
+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/lfun/Wear b/doc/lfun/Wear
index bfc8ad2..6a46903 100644
--- a/doc/lfun/Wear
+++ b/doc/lfun/Wear
@@ -1,37 +1,64 @@
+
Wear()
-FUNKTION:
- public int Wear(object ob)
+******
-DEFINIERT IN:
- /std/living/clothing.c
-ARGUMENTE:
- object ob
- Die Ruestung oder Kleidung, die angezogen wird.
+FUNKTION
+========
-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.
+ public int Wear(object ob)
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- WearArmour(), WearClothing(), Unwear(), UnwearArmour(), UnwearClothing()
- P_CLOTHING, P_ARMOURS
- FilterClothing(), FilterArmours()
+ /std/living/clothing.c
-ZULETZT GEAeNDERT:
+
+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/lfun/WearArmour b/doc/lfun/WearArmour
index 9fd8e95..a6961b2 100644
--- a/doc/lfun/WearArmour
+++ b/doc/lfun/WearArmour
@@ -1,37 +1,64 @@
+
WearArmour()
-FUNKTION:
- public int WearArmour(object ob)
+************
-DEFINIERT IN:
- /std/living/clothing.c
-ARGUMENTE:
- object ob
- Die Ruestung, die angezogen wird.
+FUNKTION
+========
-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.
+ public int WearArmour(object ob)
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- Wear(), WearClothing(), Unwear(), UnwearArmour(), UnwearClothing()
- P_CLOTHING, P_ARMOURS
- FilterClothing(), FilterArmours()
+ /std/living/clothing.c
-ZULETZT GEAeNDERT:
+
+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/lfun/WearClothing b/doc/lfun/WearClothing
index 17c0280..51cc015 100644
--- a/doc/lfun/WearClothing
+++ b/doc/lfun/WearClothing
@@ -1,37 +1,64 @@
+
WearClothing()
-FUNKTION:
- public int WearClothing(object ob)
+**************
-DEFINIERT IN:
- /std/living/clothing.c
-ARGUMENTE:
- object ob
- Das Kleidungsstuck, das angezogen wird.
+FUNKTION
+========
-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.
+ public int WearClothing(object ob)
- 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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Nicht von Hand aufrufen, es sei denn man weiss genau, was man tut. Und am
- besten auch dann nicht.
+ /std/living/clothing.c
-SIEHE AUCH:
- Wear(), WearArmour(), Unwear(), UnwearArmour(), UnwearClothing()
- P_CLOTHING, P_ARMOURS
- FilterClothing(), FilterArmours()
-ZULETZT GEAeNDERT:
+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/lfun/WearFunc b/doc/lfun/WearFunc
index 626fd64..d1d0121 100644
--- a/doc/lfun/WearFunc
+++ b/doc/lfun/WearFunc
@@ -1,80 +1,105 @@
+
WearFunc()
+**********
-FUNKTION:
- int WearFunc(object ruest, int silent, object user);
-DEFINIERT IN:
- eigenen Objekten (fuer /std/clothing/wear)
+FUNKTION
+========
-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.
+ int WearFunc(object ruest, int silent, object user);
-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.
+DEFINIERT IN
+============
-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.
+ eigenen Objekten (fuer /std/clothing/wear)
-BEISPIELE:
- Ein Helm, der nur von Elfen getragen werden kann:
- inherit "std/armour.c";
+ARGUMENTE
+=========
- #include <properties.h>
+ 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.
- create()
- {
- ::create();
- SetProp(P_ARMOUR_TYPE, AT_HELMET);
- /* zig weitere SetProp's, um den Helm zu konfigurieren */
+BESCHREIBUNG
+============
- /* WearFunc() ist im Helm selbst zu finden */
- SetProp(P_WEAR_FUNC, this_object());
- }
+ 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.
- 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;
- }
+RUeCKGABEWERT
+=============
- 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.
+ 0, wenn sich die Ruestung nicht anziehen laesst, ansonsten ungleich 0.
-SIEHE AUCH:
- P_WEAR_MSG, P_UNWEAR_MSG, P_WIELD_MSG, P_UNWIELD_MSG
- DoWear(), DoUnwear(), InformUnwear(), InformWear()
- /std/clothing/wear.c
-----------------------------------------------------------------------------
+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/lfun/WieldFunc b/doc/lfun/WieldFunc
index 23e299f..7c607e4 100644
--- a/doc/lfun/WieldFunc
+++ b/doc/lfun/WieldFunc
@@ -1,77 +1,102 @@
+
WieldFunc()
+***********
-FUNKTION:
- int WieldFunc(object weapon, int silent, object user);
-DEFINIERT IN:
- eigenen Objekten (fuer /std/weapon/combat)
+FUNKTION
+========
-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.
+ int WieldFunc(object weapon, int silent, object user);
-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.
+DEFINIERT IN
+============
-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.
+ eigenen Objekten (fuer /std/weapon/combat)
-BEISPIELE:
- Eine Waffe, die sich nicht von Zwergen zuecken laesst:
- inherit "std/weapon";
+ARGUMENTE
+=========
- #include <properties.h>
- #include <combat.h>
+ 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.
- create()
- {
- ::create();
- ... /* zig SetProp's, um die Waffe zu konfigurieren */
+BESCHREIBUNG
+============
- /* WieldFunc() ist in der Waffe selbst zu finden */
- SetProp(P_WIELD_FUNC, this_object());
- }
+ In dieser Funktion kann man zusaetzliche Abfragen vornehmen, ob sich
+ die Waffe <weapon> von <user> zuecken laesst oder nicht.
- 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");
+RUeCKGABEWERT
+=============
- /* ...und brechen das Zuecken ab. */
- return 0;
- }
+ 0, wenn die Waffe nicht gezueckt werden kann, sonst ungleich 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
----------------------------------------------------------------------------
+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/lfun/WithDraw b/doc/lfun/WithDraw
index d1532a2..1bff547 100644
--- a/doc/lfun/WithDraw
+++ b/doc/lfun/WithDraw
@@ -1,42 +1,69 @@
+
WithDraw()
-FUNKTION:
- int WithDraw(int amount);
+**********
-DEFINIERT IN:
- /p/daemon/zentralbank.c
-ARGUMENTE:
- int amount - angeforderte Geldmenge
+FUNKTION
+========
-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.
+ int WithDraw(int amount);
-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));
- ...
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Unsere Zentralbank ist korrupt, vor allem dadurch, dass in Laeden und
- an anderen Stellen Geld erzeugt wird.
+ /p/daemon/zentralbank.c
-SIEHE AUCH:
- Geldhandling: AddMoney(L), QueryMoney(L)
- Zentralbank: PayIn(L), _query_current_money(L)
- Sonstiges: /items/money.c, /sys/bank.h
+
+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/lfun/__INIT b/doc/lfun/__INIT
index 208b655..3ba4793 100644
--- a/doc/lfun/__INIT
+++ b/doc/lfun/__INIT
@@ -1,12 +1,25 @@
-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.
+__INIT()
+********
-SEE ALSO:
- initialisation(LPC)
+
+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/lfun/_query_current_money b/doc/lfun/_query_current_money
index 16b7ee5..db3663f 100644
--- a/doc/lfun/_query_current_money
+++ b/doc/lfun/_query_current_money
@@ -1,32 +1,53 @@
+
_query_current_money()
-FUNKTION:
- int _query_current_money()
+**********************
-DEFINIERT IN:
- /p/daemon/zentralbank.c
-BESCHREIBUNG:
- Es wird zurueckgegeben, wieviel Geld die Zentralbank besitzt.
+FUNKTION
+========
-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));
- }
+ int _query_current_money()
-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
+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/lfun/_unparsed_args b/doc/lfun/_unparsed_args
index cbac1bb..caf3653 100644
--- a/doc/lfun/_unparsed_args
+++ b/doc/lfun/_unparsed_args
@@ -1,28 +1,49 @@
+
_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.
+FUNKTION
+========
-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.
+ varargs string _unparsed_args(int level)
-RUeCKGABEWERT:
- Der geparste Text.
-SIEHE AUCH:
- query_command(), query_verb(), modify_command()
+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/lfun/access_rights b/doc/lfun/access_rights
index 9859761..7a99a99 100644
--- a/doc/lfun/access_rights
+++ b/doc/lfun/access_rights
@@ -1,75 +1,98 @@
+
access_rights()
+***************
-FUNKTION:
- int access_rights(string euid, string file);
-DEFINIERT IN:
- access_rights.c (muss man selber schreiben)
+FUNKTION
+========
-PARAMETER:
- euid
- Die euid desjenigen, der auf das Verzeichnis schreiben will
- file
- Name der Datei, auf die zugegriffen werden soll
+ int access_rights(string euid, string file);
-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.
+DEFINIERT IN
+============
-RUECKGABEWERT:
- 0, wenn der Zugriff verweigert wird,
- 1, wenn der Zugriff erlaubt wird.
+ access_rights.c (muss man selber schreiben)
-BEISPIELE:
- /* /d/inseln/wargon/access_rights.c */
- int access_rights(string euid, string file)
- {
- string dir, rest;
+PARAMETER
+=========
- // Catweazle darf auf alles zugreifen (*argl* ;^)
- if (euid == "catweazle")
- return 1;
+ euid
+ Die euid desjenigen, der auf das Verzeichnis schreiben will
+ file
+ Name der Datei, auf die zugegriffen werden soll
- // 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;
+BESCHREIBUNG
+============
- // Anthea darf die Karten von Aurora und der Piratenhoehle bearbeiten:
- if (dir == "MAPS" &&
- member( ({"Aurora", "Piratenhoehle" }), rest) >= 0 &&
- euid == "anthea")
- return 1;
+ access_rights() wird immer dann aufgerufen, wenn jemand, der nicht
+ sowieso schon schreibberechtigt ist, in die Datei/das Verzeichnis file
+ schreiben oder loeschen will.
- // alle anderen duerfen nicht!
- return 0;
- }
+ Anhand von euid kann man dann entscheiden, ob der Schreibzugriff erlaubt
+ wird oder nicht.
-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).
+RUECKGABEWERT
+=============
- Es wird immer nur EIN access_rights.c ausgewertet, naemlich das in der
- tiefsten Verzeichnisebene.
+ 0, wenn der Zugriff verweigert wird,
+ 1, wenn der Zugriff erlaubt wird.
- 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!
+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/lfun/buffer_hp b/doc/lfun/buffer_hp
index c3e7b1b..181751c 100644
--- a/doc/lfun/buffer_hp
+++ b/doc/lfun/buffer_hp
@@ -1,76 +1,104 @@
-FUNKTION:
- int buffer_hp( int val, int rate );
-DEFINIERT IN:
- /std/living/life.c
+buffer_hp()
+***********
-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().
+FUNKTION
+========
-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.
+ int buffer_hp( int val, int rate );
-BEISPIEL:
- #define TP this_player()
+
+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");
...
- int heilung=1;
- ...
+ AddCmd("iss","eat");
+ }
- create()
- {
- ::create();
- SetProp(P_NAME,"Heilpflanze");
+ int eat(string str)
+ {
+ notify_fail("WAS willst Du essen?\n");
+ if ( !str || !id(str) )
+ return 0;
...
- 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."));
-
+ if ( !TP->eat_food(25) )
return 1;
- }
- reset()
- {
- heilung=1;
- ::reset();
- }
+ TP->buffer_hp(20,5);
+ TP->buffer_sp(80,10);
+ heilung--;
+ write(BS("Du fuehlst langsam, wie Deine Kraefte zurueckkehren."));
- 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.
+ return 1;
+ }
-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
+ 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/lfun/buffer_sp b/doc/lfun/buffer_sp
index dc7341c..09cad72 100644
--- a/doc/lfun/buffer_sp
+++ b/doc/lfun/buffer_sp
@@ -1,36 +1,63 @@
-FUNKTION:
- int buffer_sp( int val, int rate );
-DEFINIERT IN:
- /std/living/life.c
+buffer_sp()
+***********
-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().
+FUNKTION
+========
-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.
+ int buffer_sp( int val, int rate );
-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
+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/lfun/buy_obj b/doc/lfun/buy_obj
index bf1995b..0f0b965 100644
--- a/doc/lfun/buy_obj
+++ b/doc/lfun/buy_obj
@@ -1,42 +1,65 @@
+
buy_obj()
+*********
-FUNKTION:
- static string buy_obj(mixed ob, int short);
-DEFINIERT IN:
- /std/shop.c
+FUNKTION
+========
-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.
+ static string buy_obj(mixed ob, int short);
-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);
- }
+DEFINIERT IN
+============
-SIEHE AUCH:
- sell_obj(), AddFixedObject(), RemoveFixedObject(), SetStorageRoom(),
- /std/shop.c
+ /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/lfun/catch_msg b/doc/lfun/catch_msg
index 3bf09c9..42d1950 100644
--- a/doc/lfun/catch_msg
+++ b/doc/lfun/catch_msg
@@ -1,15 +1,26 @@
+
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.
+SYNOPSIS
+========
-SEE ALSO:
- say(E), tell_room(E), tell_object(E), catch_tell(L)
+ 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/lfun/catch_tell b/doc/lfun/catch_tell
index b64832b..ff4e030 100644
--- a/doc/lfun/catch_tell
+++ b/doc/lfun/catch_tell
@@ -1,25 +1,36 @@
+
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.
+SYNOPSIS
+========
- 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.
+ void catch_tell(string)
- 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.
+DESCRIPTION
+===========
-SEE ALSO:
- enable_commands(E), say(E), tell_object(E), tell_room(E),
- write(E), catch_msg(L)
+ 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/lfun/check_and_update_timed_key b/doc/lfun/check_and_update_timed_key
index 513c261..aa96667 100644
--- a/doc/lfun/check_and_update_timed_key
+++ b/doc/lfun/check_and_update_timed_key
@@ -1,93 +1,114 @@
+
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.
+FUNKTION
+========
-BESCHREIBUNG:
- Diese Funktion hat die Aufgabe, Zeitsperren verschiedenster Art
- einfach zu ermoeglichen (z.B. die Realisierung charakter-abhaengiger
- Heilstellen u.ae.).
+ public int check_and_update_timed_key(int duration, string key)
- <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')
+DEFINIERT IN
+============
- Das Mapping P_TIMING_MAP ist NICHT zur Abfrage und / oder Manipulation
- 'per Hand' vorgesehen.
+ /std/living/life.c
-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.
+ARGUMENTE
+=========
- >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:
+ 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.
- "Die Schale ist erst halb voll, Du musst noch etwas warten."
-BEISPIELE:
- Eine Heilstelle soll jedem Spieler alle 5min zur Verfuegung stehen:
+BESCHREIBUNG
+============
- AddCmd(({"trink","trinke"}),"trink_cmd");
+ Diese Funktion hat die Aufgabe, Zeitsperren verschiedenster Art
+ einfach zu ermoeglichen (z.B. die Realisierung charakter-abhaengiger
+ Heilstellen u.ae.).
- 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.
+ <key> muss eindeutig sein, am besten verwendet man den eigenen
+ Magiernamen (und ggf. nen Gebietsnamen) als Teil des Strings.
- 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;
+ 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.
+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
-----------------------------------------------------------------------------
+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/lfun/check_restrictions b/doc/lfun/check_restrictions
index 2c815cd..e173e8f 100644
--- a/doc/lfun/check_restrictions
+++ b/doc/lfun/check_restrictions
@@ -1,149 +1,202 @@
+
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.
+FUNKTION
+========
-BESCHREIBUNG:
- Die Methode wird verwendet, um Restriktionen (zum Beispiel fuer das
- Casten eines Spells) zu pruefen. Sie wird von Spellbook und
- Gildenobjekt direkt genutzt.
+ string check_restrictions(object pl, mapping restr)
- 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.
+DEFINIERT IN
+============
- 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.
+ /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
+ 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,
+
+ P_GUILD_LEVEL
+ Gildenlevel, das das Lebewesen mindestens erreicht haben muss,
um die Aktion auszufuehren.
- P_QP
+
+ 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
+
+ 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
+
+ P_FOOD
+ Beinhaltet die Menge an Nahrung, unter der der Nahrungsspiegel
+ des Spielers liegen muss, um die Aktion noch 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
+
+ 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
+
+ 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
+
+ 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.
+ 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.
-BEISPIELE:
- // #1 Levelbeschraenkung in der Abenteurergilde
- AddSpell("feuerball",20,
- ([SI_SKILLRESTR_LEARN:([P_LEVEL:15]), ...
+ 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 "
- // #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;
- }
+ "veraergert: Ich werde Dir erst dann zu Diensten sein, wenn
+ Du " "Dich als wuerdig erwiesen hast!"]) ])
- // #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])])])
+ Aufgrund der Meldung wird empfohlen, SR_PROP nicht in
+ Restriktionen einzusetzen, die massenweise in Savefiles landen
+ (z.B. Spielersavefiles).
-SIEHE AUCH:
- execute_anything(L), AddSpell (Gilde), P_RESTRICTIONS
+ 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.
-03. Januar 2014, Arathorn
+ 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/lfun/check_timed_key b/doc/lfun/check_timed_key
index 81baff7..58c70ab 100644
--- a/doc/lfun/check_timed_key
+++ b/doc/lfun/check_timed_key
@@ -1,34 +1,52 @@
+
check_timed_key()
+*****************
-FUNKTION:
- public int check_timed_key(string key)
-
-DEFINIERT IN:
- /std/living/life.c
-ARGUMENTE:
- string key : Eindeutiger Name
+FUNKTION
+========
-BESCHREIBUNG:
- Diese Funktion hat die Aufgabe, mittels check_and_update_timed_key()
- gespeicherte Zeitsperren zu pruefen, aber dabei nicht zu veraendern.
+ public int check_timed_key(string key)
- 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.
+DEFINIERT IN
+============
- >0 <key> ist noch gesperrt.
- Der Rueckgabewert ist der Zeitpunkt, ab dem <key> wieder frei ist,
+ /std/living/life.c
-SIEHE AUCH:
- check_and_update_timed_key, eat_food, drink_alcohol, drink_soft,
- heal_self, restore_spell_points, reduce_hit_point
-----------------------------------------------------------------------------
+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/lfun/clean_up b/doc/lfun/clean_up
index 97ddf09..7c124fb 100644
--- a/doc/lfun/clean_up
+++ b/doc/lfun/clean_up
@@ -1,43 +1,67 @@
+
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!)
+FUNKTION
+========
-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.
+ int clean_up(int ref);
-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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Standardmaessig definieren nur Raeume clean_up().
+ /std/room.c
+ man kann die Funktion jedoch auch in beliebigen Objekten selbst
+ definieren.
- Die Zeiten zwischen zwei Aufrufen von clean_up() betragen momentan
- einen Tag (86400 Sekunden).
-SIEHE AUCH:
- reset(), P_NEVER_CLEAN
- memory
+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/lfun/cmd_shoot b/doc/lfun/cmd_shoot
index ccd52ce..9cbc9b9 100644
--- a/doc/lfun/cmd_shoot
+++ b/doc/lfun/cmd_shoot
@@ -1,31 +1,54 @@
+
cmd_shoot()
+***********
-FUNKTION:
- static int cmd_shoot(string str)
-DEFINIERT IN:
- /std/ranged_weapon.c
+FUNKTION
+========
-ARGUMENTE:
- string str - Schusssyntax
+ static int cmd_shoot(string str)
-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.
+DEFINIERT IN
+============
-BEISPIELE:
- RemoveCmd(({"schiess", "schiesse"})); // entferne Default-Kommando
- AddCmd(({"schleuder", "schleudere"}), #'cmd_shoot);
+ /std/ranged_weapon.c
-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
\ No newline at end of file
+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/lfun/command_me b/doc/lfun/command_me
index cdb1ef2..77a3cc5 100644
--- a/doc/lfun/command_me
+++ b/doc/lfun/command_me
@@ -1,81 +1,110 @@
+
command_me()
-FUNKTION:
- int command_me(string str)
+************
-ARGUMENTE:
- string str - auszufuehrendes Kommando
-DEFINIERT IN:
- /std/npc.c, /std/player/command.c
+FUNKTION
+========
-BESCHREIBUNG:
- Fuehrt 'str' wie ein Kommando aus, welches direkt vom Living
- abgegeben wurde.
+ int command_me(string str)
- 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.
+ARGUMENTE
+=========
- Kommandos mit oeffentlichen Kommandofunktionen (also damit alle mit
- AddCmd definierten Kommandos) koennen auch durch command()(E)
- von aussen ausgeloest werden.
+ string str - auszufuehrendes Kommando
-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";
+DEFINIERT IN
+============
- void create() {
- ::create();
- AddCmd("schleiche&heran|herum", "action_schleichen");
- }
-
- void init() {
- ::init();
- add_action("action_kriechen", "kriech", 1);
- }
+ /std/npc.c, /std/player/command.c
- 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)
+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/lfun/consume b/doc/lfun/consume
index 9979ec4..f07ece3 100644
--- a/doc/lfun/consume
+++ b/doc/lfun/consume
@@ -1,22 +1,38 @@
+
+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.
+FUNKTION
+========
-DEFINIERT IN:
- /std/living/life.c
+ public varargs int consume(mapping cinfo, int testonly);
-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.
+ Aenderung der Gesundheit eines Lebewesens durch etwas Konsumierbares.
-RUECKGABEWERT:
+
+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:
@@ -25,61 +41,75 @@
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.
+BESCHREIBUNG
+============
- 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!
+ 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.
- 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
+ Der erste Parameter gibt die Eigenschaften der Aenderung an, der zweite ob
+ ausschliesslich die Pruefung auf Anwendbarkeit erfolgen soll.
- H_CONDITIONS - Mapping der zu pruefenden Properties mit dem Umfang der
- Aenderung, erlaubte Properties siehe H_ALLOWED_CONDITIONS
+ 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!
- 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
+ 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
- Aenderungen koennen sowohl positiv als auch negativ sein.
+ H_CONDITIONS - Mapping der zu pruefenden Properties mit dem Umfang der
+ Aenderung, erlaubte Properties siehe H_ALLOWED_CONDITIONS
-BEMERKUNGEN:
- Hierbei aber bitte beachten, dass Tanken/Entanken sowie Heilungen ggf. von
- der (Heilungs-)Balance genehmigt werden muessen!
+ 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
-BEISPIELE:
- Heilung um 100 KP, 50 LP, aber nur wenn 30 P_FOOD gegessen werden kann:
+ Aenderungen koennen sowohl positiv als auch negativ sein.
- 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.
+BEMERKUNGEN
+===========
- consume(([H_EFFECTS: ([P_SP: 100, P_POISON: 2]),
- H_CONDITIONS: ([P_ALCOHOL: 15]),
- H_DISTRIBUTION: 10]) )
+ Hierbei aber bitte beachten, dass Tanken/Entanken sowie Heilungen ggf. von
+ der (Heilungs-)Balance genehmigt werden muessen!
-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
+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/lfun/create b/doc/lfun/create
index 9582609..03fc91a 100644
--- a/doc/lfun/create
+++ b/doc/lfun/create
@@ -1,78 +1,104 @@
+
create()
+********
-FUNKTION:
- protected void create();
- void create();
-DEFINIERT IN:
- allen Standardobjekten
+FUNKTION
+========
-ARGUMENTE:
- keine
+ protected void create();
+ void create();
-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
+DEFINIERT IN
+============
-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.
+ allen Standardobjekten
- 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.
+ARGUMENTE
+=========
-BEISPIELE:
- Ein Gegenstand wuerde wie folgt konfiguriert:
+ keine
- inherit "std/thing";
- #include <properties.h>
+BESCHREIBUNG
+============
- 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;
- }
+ 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()).
- // 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);
+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;
}
-SIEHE AUCH:
- create(L), reset(L)
- hook(C), create(H), create_ob(H), create_super(H, reset(H)
- create(A), reset(A)
-----------------------------------------------------------------------------
+ // 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/lfun/create_default_npc b/doc/lfun/create_default_npc
index b331c5c..09c3a14 100644
--- a/doc/lfun/create_default_npc
+++ b/doc/lfun/create_default_npc
@@ -1,55 +1,76 @@
+
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.
+FUNKTION
+========
- 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.
+ varargs void create_default_npc( int level, int maxhp );
- 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)
+BENUTZUNG
+=========
- A_STR, A_INT, A_DEX, A_CON : level
+ inherit "std/npc";
-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).
+FUNKTION
+========
-BEISPIEL:
- create_default_npc(17) ergibt:
+ Setze die Daten eines Monsters auf einen gewissen Level.
- P_LEVEL : 17
- P_MAX_HP: 178
- P_MAX_SP: 178
- P_HANDS : 170
- P_BODY : 113
- P_XP : 151300
+ 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.
- A_STR, A_INT, A_DEX, A_CON : 17
+ Wird der (optionale) Parameter maxhp weggelassen, wird dieser berechnet
+ nach:
+ maxhp = 42 + 8 * level
-SIEHE AUCH:
- Funktionen: AddExp(), GiveKillScore()
- Properties: P_XP
- P_LEVEL, P_MAX_HP, P_MAX_SP, P_HANDS, P_BODY
- Sonstiges: npcs
+ 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)
-14.Feb 2007 Gloinson
\ No newline at end of file
+ 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/lfun/create_super b/doc/lfun/create_super
index 14725a6..101531f 100644
--- a/doc/lfun/create_super
+++ b/doc/lfun/create_super
@@ -1,49 +1,75 @@
+
create_super()
+**************
-FUNKTION:
- protected void create_super();
-DEFINIERT IN:
- allen Standardobjekten
+FUNKTION
+========
-ARGUMENTE:
- keine
+ protected void create_super();
-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
+DEFINIERT IN
+============
-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.
+ allen Standardobjekten
-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)
-----------------------------------------------------------------------------
+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/lfun/defuel_drink b/doc/lfun/defuel_drink
index 67e834d..266907e 100644
--- a/doc/lfun/defuel_drink
+++ b/doc/lfun/defuel_drink
@@ -1,59 +1,87 @@
-FUNKTION:
- int defuel_drink();
-DEFINIERT IN:
- /std/living/life.c
+defuel_drink()
+**************
-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.
+FUNKTION
+========
- 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.
+ int defuel_drink();
-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)
+DEFINIERT IN
+============
-BEMERKUNG:
- Bitte defuel_drink() benutzen und nicht P_DRINK oder P_MAX_DRINK des
- manipulieren!
+ /std/living/life.c
- Es gibt keine eigene Methode fuer die Verringerung von P_ALCOHOL.
- Achtung: Nur Toiletten sollten diese Funktion im Spieler aufrufen!
+ARGUMENTE
+=========
-BEISPIEL:
- s. Bsp. zu defuel_food()
+ Keine.
-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
+
+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/lfun/defuel_food b/doc/lfun/defuel_food
index 1e89110..380c2bc 100644
--- a/doc/lfun/defuel_food
+++ b/doc/lfun/defuel_food
@@ -1,85 +1,113 @@
-FUNKTION:
- int defuel_food();
-DEFINIERT IN:
- /std/living/life.c
+defuel_food()
+*************
-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.
+FUNKTION
+========
- Es ist also NICHT moeglich, Einfluss auf die Menge des Enttankens
- zu nehmen. Das ist hier so gewollt.
+ int defuel_food();
- 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).
+DEFINIERT IN
+============
- (Konstanten kommen aus /sys/defuel.h)
+ /std/living/life.c
-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!
+ARGUMENTE
+=========
-BEISPIEL:
- int action_enttanken() {
- string msg;
- int val = this_player()->defuel_food();
+ Keine.
- 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
+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/lfun/deregister_modifier b/doc/lfun/deregister_modifier
index cbb541e..eb0c160 100644
--- a/doc/lfun/deregister_modifier
+++ b/doc/lfun/deregister_modifier
@@ -1,24 +1,42 @@
+
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.
+FUNKTION
+========
-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
+ void deregister_modifier(object modifier)
-13.Jun.2004, Muadib
\ No newline at end of file
+
+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/lfun/die b/doc/lfun/die
index ce055f8..a76a1aa 100644
--- a/doc/lfun/die
+++ b/doc/lfun/die
@@ -1,45 +1,67 @@
+
die()
+*****
-FUNKTION:
- public varargs void die(int poisondeath,int extern);
-DEFINIERT IN:
- /std/living/life.c
+FUNKTION
+========
-ARGUMENTE:
- int poisondeath
- Dieses Flag sollte bei einem Gifttod (P_POISON) gesetzt sein.
- int extern
- Intern.
+ public varargs void die(int poisondeath,int extern);
-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.
+DEFINIERT IN
+============
- 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.
+ /std/living/life.c
-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.
+ARGUMENTE
+=========
-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
+ 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/lfun/doUnwearMessage b/doc/lfun/doUnwearMessage
index e029ea2..b6128ce 100644
--- a/doc/lfun/doUnwearMessage
+++ b/doc/lfun/doUnwearMessage
@@ -1,28 +1,46 @@
+
doUnwearMessage()
+*****************
-FUNKTION:
- void doUnwearMessage(object worn_by, int all);
-DEFINIERT IN:
- /std/armour/combat.c
+FUNKTION
+========
-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.
+ void doUnwearMessage(object worn_by, int all);
-BESCHREIBUNG:
- Diese Funktion gibt beim Ausziehen einer Ruestung die entspr.
- Meldung an den Traeger und die Umgebung aus.
-RUeCKGABEWERT:
- keiner
+DEFINIERT IN
+============
-SIEHE AUCH:
- doWearMessage(), doWieldMessage(), doUnwieldMessage()
+ /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/lfun/doUnwieldMessage b/doc/lfun/doUnwieldMessage
index dbf07ce..f2245b6 100644
--- a/doc/lfun/doUnwieldMessage
+++ b/doc/lfun/doUnwieldMessage
@@ -1,25 +1,43 @@
+
doUnwieldMessage()
+******************
-FUNKTION:
- void doUnwieldMessage(object wielded_by);
-DEFINIERT IN:
- /std/weapon/combat.c
+FUNKTION
+========
-ARGUMENTE:
- wielded_by
- Das Lebewesen, dass die (Parier)Waffe bisher gezueckt hatte.
+ void doUnwieldMessage(object wielded_by);
-BESCHREIBUNG:
- Diese Funktion gibt beim Wegstecken einer Waffe die entspr.
- Meldung an den Benutzer und die Umgebung aus.
-RUeCKGABEWERT:
- keiner
+DEFINIERT IN
+============
-SIEHE AUCH:
- doWearMessage(), doUnwearMessage(), doWieldMessage()
+ /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/lfun/doWearMessage b/doc/lfun/doWearMessage
index 1962d5c..6770180 100644
--- a/doc/lfun/doWearMessage
+++ b/doc/lfun/doWearMessage
@@ -1,26 +1,44 @@
+
doWearMessage()
+***************
-FUNKTION:
- varargs void doWearMessage(int all);
-DEFINIERT IN:
- /std/armour/combat.c
+FUNKTION
+========
-ARGUMENTE:
- all
- Wurde "trage alles"/"trage alle ruestungen" eingegeben, so
- ist all gesetzt, ansonsten nicht.
+ varargs void doWearMessage(int all);
-BESCHREIBUNG:
- Diese Funktion gibt beim Anziehen einer Ruestung die entspr.
- Meldung an den Traeger und die Umgebung aus.
-RUeCKGABEWERT:
- keiner
+DEFINIERT IN
+============
-SIEHE AUCH:
- doUnwearMessage(), doWieldMessage(), doUnwieldMessage()
+ /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/lfun/doWieldMessage b/doc/lfun/doWieldMessage
index 2315faa..a3b737f 100644
--- a/doc/lfun/doWieldMessage
+++ b/doc/lfun/doWieldMessage
@@ -1,24 +1,42 @@
+
doWieldMessage()
+****************
-FUNKTION:
- void doWieldMessage();
-DEFINIERT IN:
- /std/weapon/combat.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ void doWieldMessage();
-BESCHREIBUNG:
- Diese Funktion gibt beim Zuecken einer Waffe die entspr.
- Meldung an den Benutzer und die Umgebung aus.
-RUeCKGABEWERT:
- keiner
+DEFINIERT IN
+============
-SIEHE AUCH:
- doWearMessage(), doUnwearMessage(), doUnwieldMessage()
+ /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/lfun/do_damage b/doc/lfun/do_damage
index 2d58839..91c6bc8 100644
--- a/doc/lfun/do_damage
+++ b/doc/lfun/do_damage
@@ -1,44 +1,70 @@
+
+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.
+FUNKTION
+========
-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.
+ int do_damage(int dam,mixed enemy);
-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.
+DEFINIERT IN
+============
-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
+ /std/living/life.c
-23.Feb.2004 Gloinson
\ No newline at end of file
+
+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/lfun/do_frage b/doc/lfun/do_frage
index dc08610..6c848b8 100644
--- a/doc/lfun/do_frage
+++ b/doc/lfun/do_frage
@@ -1,21 +1,42 @@
+
do_frage()
-FUNKTION:
- int do_frage(string text)
+**********
-DEFINIERT IN:
- /std/npc/info.c
-ARGUMENTE:
- string str - Schluesselwort der Frage
+FUNKTION
+========
-BESCHREIBUNG:
- Bearbeitet ein Schluesselwort, das mit "frage <wen> nach " uebergeben
- wurde. Gibt entsprechende Antworten formatiert aus.
+ int do_frage(string text)
-BEMERKUNGEN:
- Recht komplex, besser nicht ueberschreiben wenn man es nicht versteht.
-SIEHE AUCH:
- Verwandt: GetInfoArr, AddInfo
+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/lfun/do_unwear b/doc/lfun/do_unwear
index cecfa34..dd91478 100644
--- a/doc/lfun/do_unwear
+++ b/doc/lfun/do_unwear
@@ -1,34 +1,56 @@
+
do_unwear()
+***********
-FUNKTION:
- varargs int do_unwear(string str, int silent);
-DEFINIERT IN:
- /std/armour/combat.c
+FUNKTION
+========
-ARGUMENTE:
- str
- String der normalerweise dem Parameter des "ziehe"-Kommandos
- entspricht.
+ varargs int do_unwear(string str, int silent);
- 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.
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- 1, wenn alles gut ging, ansonsten 0.
+ /std/armour/combat.c
-BEMERKUNGEN:
- Wenn man Ruestungen "von aussen" ausziehen will, sollte man direkt
- UnWear() verwenden!
-SIEHE AUCH:
- do_wear(), UnWear(), RemoveFunc(), InformUnwear(),
- /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/lfun/do_wear b/doc/lfun/do_wear
index fe227d6..abf7051 100644
--- a/doc/lfun/do_wear
+++ b/doc/lfun/do_wear
@@ -1,27 +1,46 @@
+
do_wear()
+*********
-FUNKTION:
- varargs int do_wear(string str, int silent);
-DEFINIERT IN:
- /std/armour/combat.c
+FUNKTION
+========
-ARGUMENTE:
- str
- String, der normalerweise dem Parameter des
- "ziehe/trage"-Kommandos entspricht.
- silent
- 1, wenn das Anziehen ohne Meldungen durchgefuehrt werden soll.
+ varargs int do_wear(string str, int silent);
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- do_unwear(), DoWear(), WearFunc(), InformWear(), /std/armour/combat.c
+ /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/lfun/drink_alcohol b/doc/lfun/drink_alcohol
index 28ed1dd..01d0a77 100644
--- a/doc/lfun/drink_alcohol
+++ b/doc/lfun/drink_alcohol
@@ -1,83 +1,112 @@
-FUNKTION:
- public varargs int drink_alcohol(int strength, int testonly, string mytext)
-DEFINIERT IN:
- /std/living/life.c
+drink_alcohol()
+***************
-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.
+FUNKTION
+========
- Sollen neben P_ALCOHOL noch weitere Props manipuliert werden - bspw. zur
- Heilung eines Lebewesens - bietet sich die Funktion consume() an.
+ public varargs int drink_alcohol(int strength, int testonly, string mytext)
-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.
+DEFINIERT IN
+============
- Achtung: Immer erst VOR einer Heilung ausfuehren und bei Erfolg heilen.
+ /std/living/life.c
- 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));
+ARGUMENTE
+=========
- // 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);
+ 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.
- // 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;
+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);
+ }
}
-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
+
+ 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/lfun/drink_soft b/doc/lfun/drink_soft
index 4ab6e07..0f030f6 100644
--- a/doc/lfun/drink_soft
+++ b/doc/lfun/drink_soft
@@ -1,83 +1,111 @@
-FUNKTION:
- public varargs int drink_soft(int strength, int testonly, string mytext)
-DEFINIERT IN:
- /std/living/life.c
+drink_soft()
+************
-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.
+FUNKTION
+========
- Sollen neben P_DRINK noch weitere Props manipuliert werden - bspw. zur
- Heilung eines Lebewesens - bietet sich die Funktion consume() an.
+ public varargs int drink_soft(int strength, int testonly, string mytext)
-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.
+DEFINIERT IN
+============
- Achtung: Immer erst VOR einer Heilung ausfuehren und bei Erfolg heilen.
+ /std/living/life.c
- 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));
+ARGUMENTE
+=========
- // 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);
+ 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.
- // 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;
+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);
+ }
}
-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
+ 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/lfun/drop b/doc/lfun/drop
index ab8dd19..cdd372b 100644
--- a/doc/lfun/drop
+++ b/doc/lfun/drop
@@ -1,45 +1,70 @@
+
drop()
+******
-FUNKTION:
- public varargs int drop(object o, mixed msg);
-DEFINIERT IN:
- /std/living/put_and_get.c
+FUNKTION
+========
-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.
+ public varargs int drop(object o, mixed msg);
-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.
+DEFINIERT IN
+============
-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.
+ /std/living/put_and_get.c
- 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();
+ARGUMENTE
+=========
-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
+ 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/lfun/drop_obj b/doc/lfun/drop_obj
index 2f25e0f..3e1057f 100644
--- a/doc/lfun/drop_obj
+++ b/doc/lfun/drop_obj
@@ -1,28 +1,44 @@
+
drop_obj()
+**********
+
FUNKTION
- int drop_obj(object ob);
+========
-DEFINIERT IN:
+ int drop_obj(object ob);
- /std/living/put_and_get.c
-ARGUMENTE:
+DEFINIERT IN
+============
- ob Das Objekt, das von dem Lebewesen, in dem diese Funktion aufgerufen
- wird, fallengelassen werden soll.
+ /std/living/put_and_get.c
-BESCHREIBUNG:
- Das Lebewesen, in dem diese Funktion aufgerufen werden soll, laesst
- den angegebenen Gegenstand fallen, wenn dies moeglich ist.
+ARGUMENTE
+=========
-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.
+ ob Das Objekt, das von dem Lebewesen, in dem diese Funktion aufgerufen
+ wird, fallengelassen werden soll.
-SIEHE AUCH:
- find_obs(), give_obj(), pick_obj(), put_obj(), /std/living/put_and_get.c
+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/lfun/drop_objects b/doc/lfun/drop_objects
index c1045f4..93cbee5 100644
--- a/doc/lfun/drop_objects
+++ b/doc/lfun/drop_objects
@@ -1,48 +1,73 @@
+
drop_objects()
+**************
-FUNKTION:
- public varargs int drop_objects(string str, mixed msg);
-DEFINIERT IN:
- /std/living/put_and_get.c
+FUNKTION
+========
-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.
+ public varargs int drop_objects(string str, mixed msg);
-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.
+DEFINIERT IN
+============
-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.
+ /std/living/put_and_get.c
-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;
+ARGUMENTE
+=========
- filter_objects(this_player()->moved_objects(), "remove");
- return 1;
- }
+ 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.
-SIEHE AUCH:
- move(L), drop(L), P_DROP_MSG, find_objects(L), moved_objects(L)
-----------------------------------------------------------------------------
+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/lfun/eat_food b/doc/lfun/eat_food
index ec0102d..32327e2 100644
--- a/doc/lfun/eat_food
+++ b/doc/lfun/eat_food
@@ -1,86 +1,114 @@
-FUNKTION:
- public varargs int eat_food(int food, int testonly, string mytext)
-DEFINIERT IN:
- /std/living/life.c
+eat_food()
+**********
-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.
+FUNKTION
+========
- Sollen neben P_FOOD noch weitere Props manipuliert werden - bspw. zur
- Heilung eines Lebewesens - bietet sich die Funktion consume() an.
+ public varargs int eat_food(int food, int testonly, string mytext)
-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.
+DEFINIERT IN
+============
- Achtung: Immer erst VOR einer Heilung ausfuehren und bei Erfolg heilen.
+ /std/living/life.c
- 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;
+ARGUMENTE
+=========
- // 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));
+ 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.
- // 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);
- }
+BESCHREIBUNG
+============
- return 1;
- }
+ 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.
-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
+ 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/lfun/execute_anything b/doc/lfun/execute_anything
index 9c889f0..39ec45a 100644
--- a/doc/lfun/execute_anything
+++ b/doc/lfun/execute_anything
@@ -1,42 +1,64 @@
+
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
+FUNKTION
+========
-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...)]
+ protected mixed execute_anything(mixed fun, mixed 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.
+DEFINIERT IN
+============
- 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.
+ /std/util/executer.c
-SIEHE AUCH:
- check_restrictions, varargs
+
+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/lfun/exit b/doc/lfun/exit
index 190db91..f2d0b00 100644
--- a/doc/lfun/exit
+++ b/doc/lfun/exit
@@ -1,33 +1,56 @@
+
exit()
+******
-FUNKTION:
- varargs void exit(object liv, object dest);
-DEFINIERT IN:
- /std/room/description.c
+FUNKTION
+========
-ARGUMENTE:
- liv - (object) Das bewegte Lebewesen.
- dest - (object) Das Environment, in welches bewegt wird.
+ varargs void exit(object liv, object dest);
-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
+DEFINIERT IN
+============
-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.
+ /std/room/description.c
-SIEHE AUCH:
- init(), this_player(), previous_object(), caller_stack(),
- NotfiyLeave(), NotifyRemove(), NotifyDestruct()
-----------------------------------------------------------------------------
+
+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/lfun/find_obs b/doc/lfun/find_obs
index 8f44384..994ac6f 100644
--- a/doc/lfun/find_obs
+++ b/doc/lfun/find_obs
@@ -1,38 +1,53 @@
+
find_obs()
+**********
+
FUNKTION
- object* find_obs(string str, int meth)
+========
-DEFINIERT IN:
+ object* find_obs(string str, int meth)
- /std/living/put_and_get.c
-ARGUMENTE:
+DEFINIERT IN
+============
- str Der String der geparsed werden soll.
- meth Mit Hilfe dieses Parameters koennen bestimmte Bereichs-
- eingrenzungen vorgenommen werden (definiert in moving.h):
+ /std/living/put_and_get.c
- 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]
+ARGUMENTE
+=========
- <gegenstand> kann hierbei sowohl eine Objekt-ID als auch ein
- Gruppenbezeichner wie z.b. "alles" sein.
+ str Der String der geparsed werden soll.
+ meth Mit Hilfe dieses Parameters koennen bestimmte Bereichs-
+ eingrenzungen vorgenommen werden (definiert in moving.h):
-RUeCKGABEWERT:
+ 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.
- Ein Array mit allen Objekten die sich angesprochen fuehlen, oder aber 0.
-SIEHE AUCH:
+BESCHREIBUNG
+============
- drop_obj(), give_obj(), pick_obj(), put_obj(), /std/living/put_and_get.c
+ 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/lfun/get_killing_player b/doc/lfun/get_killing_player
index 16685b9..3500be1 100644
--- a/doc/lfun/get_killing_player
+++ b/doc/lfun/get_killing_player
@@ -1,39 +1,61 @@
+
get_killing_player()
+********************
-FUNKTION:
- protected object get_killing_player()
-DEFINIERT IN:
- /std/living/life.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ protected object get_killing_player()
-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.)
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- Das Objekt des Spielers, falls es ermittelt werden konnte, sonst 0.
+ /std/living/life.c
-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
-----------------------------------------------------------------------------
+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/lfun/gilde/AddSkill b/doc/lfun/gilde/AddSkill
index 21db504..6be310b 100644
--- a/doc/lfun/gilde/AddSkill
+++ b/doc/lfun/gilde/AddSkill
@@ -1,33 +1,57 @@
+
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
+FUNKTION
+========
-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.
+ varargs int AddSkill(string sname, mapping ski)
-RUECKGABWERT:
- 1 fuer Erfolg
-BEISPIEL:
- AddSkill( FIGHT(WT_CLUB), ([ OFFSET(SI_SKILLLEARN) : 1 ]) );
+DEFINIERT IN
+============
-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
+ /std/gilden_ob.c
-3. Okt 2011 Gloinson
\ No newline at end of file
+
+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/lfun/gilde/AddSpell b/doc/lfun/gilde/AddSpell
index c0ca935..027b4d6 100644
--- a/doc/lfun/gilde/AddSpell
+++ b/doc/lfun/gilde/AddSpell
@@ -1,47 +1,74 @@
+
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
+FUNKTION
+========
-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.
+ varargs int AddSpell(string verb, mapping ski)
-RUECKGABWERT:
- 1 fuer Erfolg
-BEMERKUNGEN:
- Siehe das Verhalten von QuerySpell (gilde) zum Zusammenfuegen
- der AddSpell-Informationen aus Gilde und Spellbook. Relevant
- zB fuer Lernrestriktionen.
+DEFINIERT IN
+============
-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]));
+ /std/gilden_ob.c
-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
+
+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/lfun/gilde/GuildRating b/doc/lfun/gilde/GuildRating
index 7bfb6b2..ca4ec1b 100644
--- a/doc/lfun/gilde/GuildRating
+++ b/doc/lfun/gilde/GuildRating
@@ -1,27 +1,47 @@
+
GuildRating()
-FUNKTION:
- int GuildRating(object pl)
+*************
-DEFINIERT IN:
- /std/gilden_ob.c
-ARGUMENTE:
- object pl Spieler, der geratet werden soll
+FUNKTION
+========
-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.
+ int GuildRating(object pl)
-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
\ No newline at end of file
+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/lfun/gilde/InitialSkillAbility b/doc/lfun/gilde/InitialSkillAbility
index 28a2689..afea3e9 100644
--- a/doc/lfun/gilde/InitialSkillAbility
+++ b/doc/lfun/gilde/InitialSkillAbility
@@ -1,31 +1,52 @@
+
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
+FUNKTION
+========
-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.
+ static int InitialSkillAbility(mapping ski, object pl)
-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
+DEFINIERT IN
+============
-3. Okt 2011 Gloinson
\ No newline at end of file
+ /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/lfun/gilde/LearnSkill b/doc/lfun/gilde/LearnSkill
index c381959..07a4dc9 100644
--- a/doc/lfun/gilde/LearnSkill
+++ b/doc/lfun/gilde/LearnSkill
@@ -1,35 +1,59 @@
+
LearnSkill()
-FUNKTION:
- int LearnSkill(string skill)
+************
-DEFINIERT IN:
- /std/gilden_ob.c
-ARGUMENTE:
- string skill Der zu lernende Skill
+FUNKTION
+========
-BESCHREIBUNG:
- Diese Funktion ueberprueft den Spieler auf Gildenzugehoerigkeit
- und ruft, falls kein 'skill' angegeben ist die SkillListe()
- fuer Skills auf.
+ int LearnSkill(string skill)
- 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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Fuer die Lebewesen-Skills gibt es eine gleichnamige Funktion.
- Siehe dafuer LearnSkill.
+ /std/gilden_ob.c
-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
\ No newline at end of file
+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/lfun/gilde/LearnSpell b/doc/lfun/gilde/LearnSpell
index 55c5840..385da3e 100644
--- a/doc/lfun/gilde/LearnSpell
+++ b/doc/lfun/gilde/LearnSpell
@@ -1,32 +1,53 @@
+
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
+FUNKTION
+========
-BESCHREIBUNG:
- Diese Funktion ueberprueft den Spieler auf Gildenzugehoerigkeit
- und ruft, falls kein 'spell' angegeben ist die SkillListe()
- fuer Spells auf.
+ varargs int LearnSpell(string spell, object pl)
- 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.
+DEFINIERT IN
+============
-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
+ /std/gilden_ob.c
-3. Okt 2011 Gloinson
\ No newline at end of file
+
+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/lfun/gilde/QuerySkill b/doc/lfun/gilde/QuerySkill
index 59dce12..ee3e68a 100644
--- a/doc/lfun/gilde/QuerySkill
+++ b/doc/lfun/gilde/QuerySkill
@@ -1,33 +1,54 @@
+
QuerySkill()
-FUNKTION:
- mapping QuerySkill(string skill)
+************
-DEFINIERT IN:
- /std/gilden_ob.c
-ARGUMENTE:
- string skill Name des Skills
+FUNKTION
+========
-BESCHREIBUNG:
- Liefert fuer diesen Skill die Gildeninformationen in einem
- Mapping zurueck.
+ mapping QuerySkill(string skill)
-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
+DEFINIERT IN
+============
-3. Okt 2011 Gloinson
\ No newline at end of file
+ /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/lfun/gilde/QuerySpell b/doc/lfun/gilde/QuerySpell
index 22f1965..32eff3a 100644
--- a/doc/lfun/gilde/QuerySpell
+++ b/doc/lfun/gilde/QuerySpell
@@ -1,54 +1,75 @@
+
QuerySpell()
-FUNKTION:
- mapping QuerySpell(string spell)
+************
-DEFINIERT IN:
- /std/gilden_ob.c
-ARGUMENTE:
- string spell Name des Spells
+FUNKTION
+========
-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).
+ mapping QuerySpell(string spell)
-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
+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/lfun/gilde/SkillListe b/doc/lfun/gilde/SkillListe
index 8cc2b39..200650b 100644
--- a/doc/lfun/gilde/SkillListe
+++ b/doc/lfun/gilde/SkillListe
@@ -1,27 +1,49 @@
+
SkillListe()
-FUNKTION:
- int SkillListe(int what)
+************
-DEFINIERT IN:
- /std/gilden_ob.c
-ARGUMENTE:
- int what Rueckgabeoption:
+FUNKTION
+========
-BESCHREIBUNG:
- Gibt eine Text mit Liste mit lernbaren Skills/Spells zurueck:
-
- Fuer 'what': 0 - alle; 1 - Spells; 2 - Skills.
-
- Zeigt Eintraege aus SI_SKILLINFO.
+ int SkillListe(int what)
-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
\ No newline at end of file
+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/lfun/gilde/UseSpell b/doc/lfun/gilde/UseSpell
index 96823cc..4f3724c 100644
--- a/doc/lfun/gilde/UseSpell
+++ b/doc/lfun/gilde/UseSpell
@@ -1,32 +1,53 @@
+
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
+FUNKTION
+========
-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.
+ varargs int UseSpell(object caster, string spell, mapping sinfo)
- 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.
+DEFINIERT IN
+============
-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
+ /std/gilden_ob.c
-3. Okt 2011 Gloinson
\ No newline at end of file
+
+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/lfun/gilde/austreten b/doc/lfun/gilde/austreten
index 4770bef..cde77e2 100644
--- a/doc/lfun/gilde/austreten
+++ b/doc/lfun/gilde/austreten
@@ -1,34 +1,52 @@
+
austreten()
-FUNKTION:
- varargs int austreten(int loss)
+***********
-ARGUMENTE:
- int loss Prozentsatz, um den sich die Gildenskills verschlechtern
-DEFINIERT IN:
- /std/gilden_ob.c
+FUNKTION
+========
-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.
+ varargs int austreten(int loss)
- 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%.
+ARGUMENTE
+=========
- Durch Ueberschreiben koennen hier zB Abschiedsmeldungen gesendet werden.
+ int loss Prozentsatz, um den sich die Gildenskills verschlechtern
-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
\ No newline at end of file
+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/lfun/gilde/bei_oder_aus_treten b/doc/lfun/gilde/bei_oder_aus_treten
index 0a5de78..abed024 100644
--- a/doc/lfun/gilde/bei_oder_aus_treten
+++ b/doc/lfun/gilde/bei_oder_aus_treten
@@ -1,25 +1,43 @@
+
bei_oder_aus_treten()
-FUNKTION:
- int bei_oder_aus_treten(string str)
+*********************
-ARGUMENTE:
- string str Spielerparameter
-DEFINIERT IN:
- /std/gilden_ob.c
+FUNKTION
+========
-BESCHREIBUNG:
- Aus- oder Eintrittsfunktion, ruft beitreten() bzw. austreten() auf.
- Wird im Std-Gildenraum per AddCmd zur Verfuegung gestellt.
+ int bei_oder_aus_treten(string str)
-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
\ No newline at end of file
+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/lfun/gilde/beitreten b/doc/lfun/gilde/beitreten
index 3938f7b..6e5a957 100644
--- a/doc/lfun/gilde/beitreten
+++ b/doc/lfun/gilde/beitreten
@@ -1,28 +1,43 @@
+
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.
+FUNKTION
+========
- Der Gildenmaster loest ggf ein EVT_GUILD_CHANGE aus. Dabei werden
- E_OBJECT, E_GUILDNAME, E_LAST_GUILDNAME entsprechend gesetzt.
+ int beitreten()
- 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
+DEFINIERT IN
+============
-3. Okt 2011 Gloinson
\ No newline at end of file
+ /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/lfun/give b/doc/lfun/give
index 39a2624..866c1e3 100644
--- a/doc/lfun/give
+++ b/doc/lfun/give
@@ -1,43 +1,65 @@
+
give()
+******
-FUNKTION:
- public varargs int give(object o, object dest, mixed msg);
-DEFINIERT IN:
- /std/living/put_and_get.c
+FUNKTION
+========
-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.
+ public varargs int give(object o, object dest, mixed msg);
-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.
+DEFINIERT IN
+============
-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.
+ /std/living/put_and_get.c
- 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
+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/lfun/give_notify b/doc/lfun/give_notify
index 010d68e..ef316cb 100644
--- a/doc/lfun/give_notify
+++ b/doc/lfun/give_notify
@@ -1,59 +1,87 @@
+
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
+FUNKTION
+========
-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!
+ void give_notify(object obj);
-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
- }
+DEFINIERT IN
+============
- 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).
+ /std/npc/put_and_get.c
-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
+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/lfun/give_obj b/doc/lfun/give_obj
index 59f8c99..753fd09 100644
--- a/doc/lfun/give_obj
+++ b/doc/lfun/give_obj
@@ -1,27 +1,43 @@
+
give_obj()
+**********
+
FUNKTION
- int give_obj(object ob, object where)
+========
-DEFINIERT IN:
+ int give_obj(object ob, object where)
- /std/living/put_and_get.c
-ARGUMENTE:
+DEFINIERT IN
+============
- ob Das Objekt, das abgegeben werden soll.
- where Das Lebewesen, dass das Objekt erhaelt.
+ /std/living/put_and_get.c
-BESCHREIBUNG:
- Das Lebewesen, in dem diese Funktion aufgerufen werden soll, gibt
- den angegebenen Gegenstand (ob) an das angegebene Lebewesen (where).
+ARGUMENTE
+=========
-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.
+ ob Das Objekt, das abgegeben werden soll.
+ where Das Lebewesen, dass das Objekt erhaelt.
-SIEHE AUCH:
- pick_obj(), drop_obj(), put_obj(), find_obs(), /std/living/put_and_get.c
+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/lfun/heal_self b/doc/lfun/heal_self
index 5f60547..53697a2 100644
--- a/doc/lfun/heal_self
+++ b/doc/lfun/heal_self
@@ -1,49 +1,68 @@
+
heal_self()
+***********
-FUNKTION:
- void heal_self(int points);
-ARGUMENTE:
- points: Die dem Lebewesen zukommende Heilung.
+FUNKTION
+========
-BESCHREIBUNG:
- Dem Lebewesen werden points Lebens- und Konzentrationspunkte
- gutgeschrieben und auf die aktuellen addiert. Es werden aber nicht
- die maximalen Werte ueberschritten.
+ void heal_self(int points);
-RUECKGABEWERT:
- Keiner
-BEISPIELE:
-
- AddCmd("pflueck&beere","pfluecke_cmd","Was moechtest Du pfluecken?");
+ARGUMENTE
+=========
- 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;
- }
+ points: Die dem Lebewesen zukommende Heilung.
- 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.
+BESCHREIBUNG
+============
- Bei Heilstellen sollte eine evtl. Heilung des Spielers mit der eigens
- dafuer eingerichteten Funktion check_and_update_timed_key realisiert
- werden.
+ Dem Lebewesen werden points Lebens- und Konzentrationspunkte
+ gutgeschrieben und auf die aktuellen addiert. Es werden aber nicht
+ die maximalen Werte ueberschritten.
-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
-----------------------------------------------------------------------------
+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/lfun/heart_beat b/doc/lfun/heart_beat
index 6a314bd..475a781 100644
--- a/doc/lfun/heart_beat
+++ b/doc/lfun/heart_beat
@@ -1,42 +1,57 @@
+
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.
+FUNKTION
+========
-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.
+ protected void heart_beat();
- 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().
+DEFINIERT IN
+============
-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]) );
+ /std/living/life.c
+ /std/living/combat.c
+ und anderen...
+ kann auch in beliebigen Objekten selbst definiert werden.
-SIEHE AUCH:
- Efuns: set_heart_beat(), absolute_hb_count(), set_next_reset()
- Fehler: make_immortal(L)
-----------------------------------------------------------------------------
+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/lfun/id b/doc/lfun/id
index 7cf5aed..4921395 100644
--- a/doc/lfun/id
+++ b/doc/lfun/id
@@ -1,76 +1,99 @@
+
id()
+****
-FUNKTION:
- varargs int id(string str, int lvl);
-DEFINIERT IN:
- /std/thing/description.c
- /std/player/base.c
+FUNKTION
+========
-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.
+ varargs int id(string str, int lvl);
-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!
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- 1, wenn sich das Objekt von str angesprochen fuehlt, ansonsten 0.
+ /std/thing/description.c
+ /std/player/base.c
-BEISPIELE:
- Angenommen, ein Objekt habe folgende Bezeichner:
- AddId( "murmel" );
- AddAdjective( "runde" );
+ARGUMENTE
+=========
- Dann liefern die angegebenen id()-Aufrufe folgende Ergebnisse:
+ 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.
- 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.:
+BESCHREIBUNG
+============
- AddId( "geld" );
- AddSingularId( "muenze" );
- AddPluralId( "muenzen" );
+ 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.
- Nach fuehlen sich nach den folgenden id()-Aufrufen folgende Anzahlen
- angesprochen:
+ 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!
- 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.
+RUeCKGABEWERT
+=============
-SIEHE AUCH:
- AddId(), AddAdjective(), AddSingularId(), AddPluralId(), present(),
- match_ids(), /std/thing/description.c, /std/unit.c
+ 1, wenn sich das Objekt von str angesprochen fuehlt, ansonsten 0.
-6. Sep 2012 Gloinson
\ No newline at end of file
+
+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/lfun/init b/doc/lfun/init
index f9d0cad..481eec2 100644
--- a/doc/lfun/init
+++ b/doc/lfun/init
@@ -1,65 +1,91 @@
+
init()
+******
-FUNKTION:
- void init();
-DEFINIERT IN:
- /std/room/description.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ void init();
-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.
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- keiner
+ /std/room/description.c
-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:
+ARGUMENTE
+=========
- 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
+ keine
- Gelangt dagegen ein nichtlebendiges Objekt nach D, so sieht das Ganze
- wie folgt aus:
- X->init(); // this_player() == L1
+BESCHREIBUNG
+============
-SIEHE AUCH:
- exit(), AddCmd(), add_action(),
- NotifyInsert()
-----------------------------------------------------------------------------
+ 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/lfun/insert_sensitive_inv b/doc/lfun/insert_sensitive_inv
index 5b54df4..513632a 100644
--- a/doc/lfun/insert_sensitive_inv
+++ b/doc/lfun/insert_sensitive_inv
@@ -1,21 +1,36 @@
-insert_sensitive_inv
-FUNKTION:
- void insert_sensitive_inv(object ob, string key,
- int threshold, mixed *opt)
-DEFINIERT IN:
- /std/container/inventory.c
+insert_sensitive_inv()
+**********************
-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
+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/lfun/insert_sensitive_inv_trigger b/doc/lfun/insert_sensitive_inv_trigger
index 766f0f5..edb78f8 100644
--- a/doc/lfun/insert_sensitive_inv_trigger
+++ b/doc/lfun/insert_sensitive_inv_trigger
@@ -1,21 +1,36 @@
-insert_sensitive_inv_trigger
-FUNKTION:
- void insert_sensitive_inv_trigger(object ob, string key,
- int threshold, mixed *opt)
-DEFINIERT IN:
- /std/container/inventory.c
+insert_sensitive_inv_trigger()
+******************************
-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
+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/lfun/int_long b/doc/lfun/int_long
index 7513e87..931e132 100644
--- a/doc/lfun/int_long
+++ b/doc/lfun/int_long
@@ -1,64 +1,91 @@
+
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!)
+FUNKTION
+========
-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.
+ varargs string int_long(mixed viewer, mixed viewpoint, int flags)
- Ist Viewer ein Magier mit eingeschaltetem Magiermodus, so wird der
- Beschreibung der Dateiname des Raumes vorangestellt.
-RUeCKGABEWERT:
- Die Langbeschreibung des Raumes von innen.
+DEFINIERT IN
+============
-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.
+ /std/room/description.c
-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));
- }
+ARGUMENTE
+=========
-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
+ 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/lfun/int_short b/doc/lfun/int_short
index e4a8d3a..aabd547 100644
--- a/doc/lfun/int_short
+++ b/doc/lfun/int_short
@@ -1,58 +1,85 @@
+
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!)
+FUNKTION
+========
-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.
+ string int_short(mixed viewer, mixed viewpoint);
- Ist Viewer ein Magier mit eingeschaltetem Magiermodus, so wird der
- Beschreibung der Dateiname des Raumes vorangestellt.
-RUeCKGABEWERT:
- Die Kurzbeschreibung des Raumes von innen.
+DEFINIERT IN
+============
-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.
+ /std/room/description.c
-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));
- }
+ARGUMENTE
+=========
-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
+ 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/lfun/is_class_member b/doc/lfun/is_class_member
index 7019447..1018e71 100644
--- a/doc/lfun/is_class_member
+++ b/doc/lfun/is_class_member
@@ -1,155 +1,174 @@
+
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)
+FUNKTION
+========
-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:
+ int is_class_member(string|string* class);
- 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:
+DEFINIERT IN
+============
- 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.
+ /std/thing/description.c
- 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.
+ARGUMENTE
+=========
-SIEHE AUCH:
- AddClass(), RemoveClass(), /std/thing/description.c
- P_CLASS
+ 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/lfun/lfun b/doc/lfun/lfun
index eadd45a..6e35081 100644
--- a/doc/lfun/lfun
+++ b/doc/lfun/lfun
@@ -1,12 +1,25 @@
-NAME:
- lfun()
-DESCRIPTION:
- This directory contains descriptions for the lfuns used by
- Amylaar's version of the LPC parser.
+lfun()
+******
- 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)
+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/lfun/locate_objects b/doc/lfun/locate_objects
index 1d56e9a..5854980 100644
--- a/doc/lfun/locate_objects
+++ b/doc/lfun/locate_objects
@@ -1,54 +1,79 @@
+
locate_objects()
+****************
-FUNKTION:
- object *locate_objects(string desc, int info);
-DEFINIERT IN:
- /std/container/restrictions.c
+FUNKTION
+========
-ARGUMENTE:
- desc
- Die Umschreibung des gesuchten Objektes.
+ object *locate_objects(string desc, int info);
- 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:
+DEFINIERT IN
+============
- Ist desc von der Form "<id>", so wird das Ergebnis von
- present_objects(desc) zurueckgegeben.
+ /std/container/restrictions.c
- 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.
+ARGUMENTE
+=========
-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!
+ desc
+ Die Umschreibung des gesuchten Objektes.
-BEISPIELE:
- Was steckt alles dem Beutel, den der Spieler bei sich traegt?
+ info
+ Ist ungleich 0, wenn diese Funktion von /std/living/put_and_get.c
+ aus aufgerufen wurde.
- 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.
+BESCHREIBUNG
+============
-SIEHE AUCH:
- present_objects(), /std/container/restrictions.c
+ 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/lfun/logon b/doc/lfun/logon
index 700f1e0..4fb7117 100644
--- a/doc/lfun/logon
+++ b/doc/lfun/logon
@@ -1,15 +1,26 @@
+
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.
+SYNOPSIS
+========
-SEE ALSO:
- connect(M)
+ 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/lfun/long b/doc/lfun/long
index 34ac4f9..a186cf9 100644
--- a/doc/lfun/long
+++ b/doc/lfun/long
@@ -1,31 +1,55 @@
+
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")
+FUNKTION
+========
-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.
+ varargs string long(int mode);
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- Aehnliches: short()
- Properties: P_LONG, P_INVIS, P_TRANSPARENT
- Sonstiges: make_invlist()
+ /std/thing/description.c
-11. Mai 2004 Gloinson
\ No newline at end of file
+
+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/lfun/make_immortal b/doc/lfun/make_immortal
index a567229..9d0f402 100644
--- a/doc/lfun/make_immortal
+++ b/doc/lfun/make_immortal
@@ -1,27 +1,44 @@
-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
+
+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/lfun/make_invlist b/doc/lfun/make_invlist
index effbcca..379b47c 100644
--- a/doc/lfun/make_invlist
+++ b/doc/lfun/make_invlist
@@ -1,38 +1,59 @@
+
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
+FUNKTION
+========
-BESCHREIBUNG:
- Die Kurzbeschreibungen der Objekte in inv werden zu einer Liste
- zusammengefasst (eine Zeile pro Objekt). Unsichtbare Objekte tauchen in
- dieser Liste nicht auf.
+ varargs mixed make_invlist(object viewer, mixed inv, int flags)
- 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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- Kommandokette: short()
- Properties: P_SHORT, P_INVIS, P_WANTS_TO_LEARN
- Sonstiges: P_REFERENCE_OBJECT
+ /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/lfun/master/AddWizardForUID b/doc/lfun/master/AddWizardForUID
index c58463b..249e27c 100644
--- a/doc/lfun/master/AddWizardForUID
+++ b/doc/lfun/master/AddWizardForUID
@@ -1,47 +1,74 @@
+
AddWizardForUID()
+*****************
-FUNKTION:
- string* AddWizardForUID(string uid, string wizard);
-DEFINIERT IN:
- /secure/master/userinfo.c
+FUNKTION
+========
-ARGUMENTE:
- uid
- Die UID, fuer die man einen (weiteren) verantwortlichen Magier
- explizit eintragen moechte.
- wizard
- Der Magier, den man eintragen moechte.
+ string* AddWizardForUID(string uid, string wizard);
-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.
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- Zurueckgeliefert wird ein Array von Strings, jedes Element ist eine UID,
- fuer die dier Magier jetzt explizit eingetragen ist.
+ /secure/master/userinfo.c
-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));
+ARGUMENTE
+=========
-SIEHE AUCH:
- QueryWizardsForUID(), QueryUIDsForWizard,
- RemoveWizardFromUID()
+ 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/lfun/master/QueryUIDAlias b/doc/lfun/master/QueryUIDAlias
index 0ea844c..8f58509 100644
--- a/doc/lfun/master/QueryUIDAlias
+++ b/doc/lfun/master/QueryUIDAlias
@@ -1,43 +1,65 @@
+
QueryUIDAlias()
+***************
-FUNKTION:
- varargs string* QueryUIDsForWizard(string uidalias, int recursive);
-DEFINIERT IN:
- /secure/master/userinfo.c
+FUNKTION
+========
-ARGUMENTE:
- uidalias
- UID, die expandiert werden soll.
- recursive (optional)
- Gibt an, ob QueryUIDAlias() (indirekt) rekursiv aufgerufen wurde.
- Sollte normalerweise nicht per Hand gesetzt werden.
+ varargs string* QueryUIDsForWizard(string uidalias, int recursive);
-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).
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- Zurueckgeliefert wird ein Array von Strings, jedes Element ist eine UID.
- Sollte uidaliase keines der o.g. sein, wird ein ({uidalias}) geliefert.
+ /secure/master/userinfo.c
-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()
+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/lfun/master/QueryUIDsForWizard b/doc/lfun/master/QueryUIDsForWizard
index a4028c1..e0d5816 100644
--- a/doc/lfun/master/QueryUIDsForWizard
+++ b/doc/lfun/master/QueryUIDsForWizard
@@ -1,42 +1,64 @@
+
QueryUIDsForWizard()
+********************
-FUNKTION:
- varargs string* QueryUIDsForWizard(string wizname, int recursive);
-DEFINIERT IN:
- /secure/master/userinfo.c
+FUNKTION
+========
-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.
+ varargs string* QueryUIDsForWizard(string wizname, int recursive);
-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.
+DEFINIERT IN
+============
-BEISPIELE:
- string *uids = master()->QueryUIDsForWizard("ennox");
- // uids enthaelt nun:
- // ({"ennox","d.anfaenger.ennox","d.schattenwelt.ennox",
- // "p.service.ennox","GUILD.chaos","p.chaos"})
+ /secure/master/userinfo.c
-SIEHE AUCH:
- QueryWizardsForUID(),
- AddWizardForUID(), RemoveWizardFromUID()
+
+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/lfun/master/QueryWizardsForUID b/doc/lfun/master/QueryWizardsForUID
index 93095b6..6ddbdc3 100644
--- a/doc/lfun/master/QueryWizardsForUID
+++ b/doc/lfun/master/QueryWizardsForUID
@@ -1,46 +1,71 @@
+
QueryWizardsForUID()
+********************
-FUNKTION:
- varargs string* QueryWizardsForUID(string uid, int recursive);
-DEFINIERT IN:
- /secure/master/userinfo.c
+FUNKTION
+========
-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.
+ varargs string* QueryWizardsForUID(string uid, int recursive);
-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.
+DEFINIERT IN
+============
-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...
+ /secure/master/userinfo.c
-BEISPIELE:
- string *wiz = master()->QueryWizards("GUILD.klerus");
- // wiz enthaelt nun: ({"morgoth","magdalena"})
-SIEHE AUCH:
- QueryUIDsForWizard(),
- AddWizardForUID(), RemoveWizardFromUID()
+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/lfun/master/RemoveWizardFromUID b/doc/lfun/master/RemoveWizardFromUID
index da97132..1fdeba5 100644
--- a/doc/lfun/master/RemoveWizardFromUID
+++ b/doc/lfun/master/RemoveWizardFromUID
@@ -1,38 +1,62 @@
+
RemoveWizardFromUID()
+*********************
-FUNKTION:
- string* RemoveWizardFromUID(string uid, string wizard);
-DEFINIERT IN:
- /secure/master/userinfo.c
+FUNKTION
+========
-ARGUMENTE:
- uid
- Die UID, fuer die man einen zustaendigen Magier austragen will.
- wizard
- Der Magier, den man austragen moechte.
+ string* RemoveWizardFromUID(string uid, string wizard);
-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. ;-)
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- Zurueckgeliefert wird ein Array von Strings, jedes Element ist eine UID,
- fuer die dier Magier jetzt explizit eingetragen ist.
+ /secure/master/userinfo.c
-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()
+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/lfun/match_ids b/doc/lfun/match_ids
index d2c985b..48f368f 100644
--- a/doc/lfun/match_ids
+++ b/doc/lfun/match_ids
@@ -1,47 +1,69 @@
+
match_ids()
+***********
-FUNKTION:
- int match_ids(string *list);
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-ARGUMENTE:
- *list String-Array mit zu testenden IDs
+ int match_ids(string *list);
-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.
+DEFINIERT IN
+============
-BEISPIELE:
- Angenommen, ein Objekt habe folgende Bezeichner:
+ /std/thing/description.c
- AddId( ({"murmel","kugel","glasmurmel","glaskugel"}) );
- AddAdjective( "rund" );
- Dann liefern die angegebenen match_ids()-Aufrufe folgende Ergebnisse:
+ARGUMENTE
+=========
- 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
+ *list String-Array mit zu testenden IDs
-SIEHE AUCH:
- AddId(), AddAdjective(), AddSingularId(), AddPluralId(), present(),
- id(), /std/thing/description.c, /std/unit.c
-----------------------------------------------------------------------------
+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/lfun/move b/doc/lfun/move
index b323c34..bd9d924 100644
--- a/doc/lfun/move
+++ b/doc/lfun/move
@@ -1,212 +1,242 @@
+
+move()
+******
+
move()
-FUNKTION:
- Fuer unbelebte Gegenstaende (/std/thing):
- varargs int move(object|string dest, int method);
+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);
+ 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).
+DEFINIERT IN
+============
- method
- Die Art der Bewegung (eine der unten aufgefuehrten Arten; es
- koennen auch mehrere zusammenge-ODER-t werden).
+ /std/thing/moving.c
+ /std/living/moving.c
- 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.
+ARGUMENTE
+=========
- 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.
+ dest
+ Das Zielobjekt (entweder der Dateiname oder das Objekt selbst).
-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.
+ method
+ Die Art der Bewegung (eine der unten aufgefuehrten Arten; es
+ koennen auch mehrere zusammenge-ODER-t werden).
- 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).
+ dir
+ Die Richtung, in die ein Lebewesen geht. Normalerweise ist das die
+ eingeschlagene Laufrichtung (zB. "nach Norden").
- 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.
+ 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.
- 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.
+ 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.
- 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.
+BESCHREIBUNG
+============
- M_SILENT
- Es werden beim Bewegen keine Meldungen ausgegeben. Dieser
- Parameter wirkt sich nur auf das Bewegen von Lebenwesen aus.
+ Es wird versucht, das Objekt in das Zielobjekt dest zu bewegen.
+ Abhaengig vom momentanen Aufenthaltsort und dem Zielobjekt ist die
+ Bewegungsmethode method zu waehlen.
- M_GET
- Das Objekt wird von einem unbelebten Objekt (zB. einem Raum, einer
- Leiche, einem Beutel) in ein lebendes Objekt (Spieler oder NPC)
- bewegt.
+ 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_PUT
- Das Objekt wird von einem lebenden Objekt in ein unbelebtes Objekt
- bewegt.
+ 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_GIVE
- Das Objekt wird von einem Lebewesen an ein anderes Lebewesen
- weitergereicht.
+ 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_MOVE_ALL (Nur fuer Objekte, die /std/unit.c erben)
- Es wird die gesamte Menge bewegt, nicht nur ein Teil.
+ M_NO_SHOW
+ Beim Bewegen von Lebewesen bekommen diese die Beschreibung des
+ Zielraumes nicht ausgegeben.
- Soll das Objekt auf jeden Fall und ohne jede Abfrage bewegt werden, so
- reicht es, als method M_NOCHECK zu uebergeben.
+ M_NO_ATTACK
+ Beim Bewegen von Lebewesen bekommen diese keinen
+ Begruessungsschlag, wenn ein Feind im Zielraum steht.
- 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.
+ M_SILENT
+ Es werden beim Bewegen keine Meldungen ausgegeben. Dieser
+ Parameter wirkt sich nur auf das Bewegen von Lebenwesen aus.
- 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.
+ M_GET
+ Das Objekt wird von einem unbelebten Objekt (zB. einem Raum, einer
+ Leiche, einem Beutel) in ein lebendes Objekt (Spieler oder NPC)
+ bewegt.
-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.
+ M_PUT
+ Das Objekt wird von einem lebenden Objekt in ein unbelebtes Objekt
+ bewegt.
- 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.
+ M_GIVE
+ Das Objekt wird von einem Lebewesen an ein anderes Lebewesen
+ weitergereicht.
- 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.
+ M_MOVE_ALL (Nur fuer Objekte, die /std/unit.c erben)
+ Es wird die gesamte Menge bewegt, nicht nur ein Teil.
-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.
+ Soll das Objekt auf jeden Fall und ohne jede Abfrage bewegt werden, so
+ reicht es, als method M_NOCHECK zu uebergeben.
- ME_PLAYER
- Lebewesen lassen sich nicht ohne weiteres bewegen. Es muss
- mindestens eine der Methoden M_NOCHECK, M_GO oder M_TPORT
- angegeben werden.
+ 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.
- ME_TOO_HEAVY
- Das Zielobjekt kann dieses Objekt aus Gewichtsgruenden nicht mehr
- aufnehmen.
+ 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.
- 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).
+ANMERKUNG
+=========
- ME_CANT_BE_DROPPED
- Das Objekt kann nicht fallen gelassen werden (zB. weil P_NODROP
- gesetzt ist).
+ 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. ;-)
- 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
+ Wenn Livings bewegt werden, sorgt move() automatisch in Abhaengigkeit
+ von P_PARA dafuer, dass das Lebewesen in der korrekten (Parallel-)Welt
+ landet.
- ME_TOO_HEAVY_FOR_ENV
- Ein Objekt kann einen Behaelter nicht verlassen, da es dem
- Lebewesen sonst zu schwer wuerde.
+ 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.
- TOO_MANY_OBJECTS
- Das Zielobjekt kann soviele Objekte nicht mehr aufnehmen.
+ 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.
- 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.
+RUeCKGABEWERT
+=============
-BEISPIELE:
- o Ein Objekt "gibt sich" dem Spieler:
+ 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(this_player(), M_GET);
- o Ein Lebewesen wird in die Abenteurergilde teleportiert:
- lv->move("/gilden/abenteurer", M_TPORT);
+ MOVE_OK
+ Die Bewegung wurde erfolgreich abgeschlossen.
- o Ein Spieler "wird in die Gilde gegangen":
+ ME_PLAYER
+ Lebewesen lassen sich nicht ohne weiteres bewegen. Es muss
+ mindestens eine der Methoden M_NOCHECK, M_GO oder M_TPORT
+ angegeben werden.
- this_player()->move("/gilden/abenteurer", M_GO, "in die Gilde");
+ ME_TOO_HEAVY
+ Das Zielobjekt kann dieses Objekt aus Gewichtsgruenden nicht mehr
+ aufnehmen.
- Spieler, die mit ihm im gleichen Raum stehen, sehen folgende
- Meldung:
- "<name> geht in die Gilde."
+ ME_CANT_TPORT_IN
+ Das Zielobjekt verbietet das Teleportieren in sich hinein (nur bei
+ M_TPORT ohne M_NOCHECK).
- o Ein Spieler schwimmt durchs Meer:
+ 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).
- this_player()->move("meer_xy", M_GO, "nach Norden", "schwimmt",
- "schwimmt herein");
+ ME_CANT_BE_DROPPED
+ Das Objekt kann nicht fallen gelassen werden (zB. weil P_NODROP
+ gesetzt ist).
- Spieler in seinem Startraum sehen "<name> schwimmt nach Norden.",
- Spieler in seinem Zielraum sehen "<name> schwimmt herein."
+ ME_CANT_BE_TAKEN
+ Das Objekt kann nicht genommen werden (zB. weil P_NOGET gesetzt
+ ist).
-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
- -----------------------------------------------------------------------
+ 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/lfun/moved_objects b/doc/lfun/moved_objects
index edcbd6e..8a5b536 100644
--- a/doc/lfun/moved_objects
+++ b/doc/lfun/moved_objects
@@ -1,30 +1,52 @@
+
moved_objects()
+***************
-FUNKTION:
- public object *moved_objects(void);
-DEFINIERT IN:
- /std/living/put_and_get.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ public object *moved_objects(void);
-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.
+DEFINIERT IN
+============
-BEISPIELE:
- siehe drop_objects() und give_objects()
+ /std/living/put_and_get.c
-SIEHE AUCH:
- drop_objects(L), give_objects(L), pick_objects(L), put_objects(L),
- show_objects(L), NotifyMove(L)
-----------------------------------------------------------------------------
+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/lfun/moved_where b/doc/lfun/moved_where
index 8bb7e9c..640acae 100644
--- a/doc/lfun/moved_where
+++ b/doc/lfun/moved_where
@@ -1,28 +1,50 @@
+
moved_where()
+*************
-FUNKTION:
- public object moved_where(void);
-DEFINIERT IN:
- /std/living/put_and_get.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ public object moved_where(void);
-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.
+DEFINIERT IN
+============
-BEISPIEL:
- siehe give_objects()
+ /std/living/put_and_get.c
-SIEHE AUCH:
- put_objects(L), give_objects(L), show_objects(L), NotifyInsert(L),
- P_LAST_CONTENT_CHANGE
-----------------------------------------------------------------------------
+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/lfun/muster b/doc/lfun/muster
index d519f69..aa7279c 100644
--- a/doc/lfun/muster
+++ b/doc/lfun/muster
@@ -1,16 +1,33 @@
+
muster()
+********
-FUNKTION:
- type muster(...)
-
-ARGUMENTE:
-
-BESCHREIBUNG:
-RUECKGABEWERT:
-
-BEMERKUNG:
-
-BEISPIEL:
+FUNKTION
+========
-SIEHE AUCH:
+ type muster(...)
+
+
+ARGUMENTE
+=========
+
+
+BESCHREIBUNG
+============
+
+
+RUECKGABEWERT
+=============
+
+
+BEMERKUNG
+=========
+
+
+BEISPIEL
+========
+
+
+SIEHE AUCH
+==========
diff --git a/doc/lfun/name b/doc/lfun/name
index 74eac45..3509366 100644
--- a/doc/lfun/name
+++ b/doc/lfun/name
@@ -1,54 +1,81 @@
+
+name()
+******
+
name()|Name()
-FUNKTION:
- varargs string name(int casus, int demon);
- varargs string Name(int casus, int demon);
-DEFINIERT IN:
- /std/thing/description.c
+FUNKTION
+========
-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.
+ varargs string name(int casus, int demon);
+ varargs string Name(int casus, int demon);
-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.
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- String mit dem Namen des Objektes.
+ /std/thing/description.c
-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.
+ARGUMENTE
+=========
-BEISPIELE:
- Wenn das Objekt ein Ball mit P_NAME="Ball" und P_NAME_ADJ="klein" ist,
- so liefern die folgenden Aufrufe die angegebenen Ergebnisse:
+ 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.
- 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()
+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/lfun/notify_player_change b/doc/lfun/notify_player_change
index 1765af6..34c4024 100644
--- a/doc/lfun/notify_player_change
+++ b/doc/lfun/notify_player_change
@@ -1,56 +1,82 @@
+
+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)
+FUNKTION
+========
-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
+ void /notify_player_change(object who, int rein)
+ void /std/player/base::notify_player_change(string who, int rein,
+ int invis)
- 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");
- }
- }
- }
+GERUFEN VON
+===========
-SIEHE AUCH:
- RegisterEvent mit (EVT_LIB_LOGIN, EVT_LIB_LOGOUT)
- erwarte
+ /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/lfun/obsolete/AddHpHook b/doc/lfun/obsolete/AddHpHook
index e227951..5a2adce 100644
--- a/doc/lfun/obsolete/AddHpHook
+++ b/doc/lfun/obsolete/AddHpHook
@@ -1,29 +1,52 @@
-********************* 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
+********************* OBSOLETE LFUN
+*********************************** * Diese Efun bitte nicht mehr
+benutzen, sondern stattdessen die * * Hooks (s. /doc/std/hooks).
+* *******************************************************************
+**** AddHpHook()
-ARGUMENTE:
- ob - das Objekt, das sich eintragen moechte.
-BESCHREIBUNG:
- Traegt ein Objekt in P_HP_HOOKS ein, wenn es nicht schon darin steht.
+FUNKTION
+========
- Aendern sich beim Spieler dann HP oder KP (nicht durch Set()), wird
- an allen eingetragenen Objekten NotifyHpChange() gerufen.
+ int AddHpHook(object ob)
-RUECKGABEWERT:
- 1, wenn Erfolg, 0 sonst
-SIEHE AUCH:
- Gegenpart: RemoveHpHook()
- Props: P_HP_HOOKS, P_HP
- Verwandt: reduce_hit_points(), do_damage(), buffer_hp()
+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/lfun/obsolete/AddInsertHook b/doc/lfun/obsolete/AddInsertHook
index 5e80272..9a372ba 100644
--- a/doc/lfun/obsolete/AddInsertHook
+++ b/doc/lfun/obsolete/AddInsertHook
@@ -1,59 +1,85 @@
-********************* OBSOLETE LFUN ***********************************
-* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die *
-* Hooks (s. /doc/std/hooks). *
-***********************************************************************
+
AddInsertHook()
+***************
-FUNKTION:
- void AddInsertHook(object ob);
+********************* OBSOLETE LFUN
+*********************************** * Diese Efun bitte nicht mehr
+benutzen, sondern stattdessen die * * Hooks (s. /doc/std/hooks).
+* *******************************************************************
+**** AddInsertHook()
-DEFINIERT IN:
- /std/player/restrictions.c
-ARGUMENTE:
- ob - Das Objekt, das informiert werden soll, wenn ein Objekt dem
- Spielerinventar hinzugefuegt wurde.
+FUNKTION
+========
-BESCHREIBUNG:
- (Diese Funktionalitaet wurde ersetzt durch den allgemeinen Hook
- H_HOOK_INSERT und ist nur noch aus Gruenden der Kompatibilitaet
- vorhanden.)
+ void AddInsertHook(object ob);
- 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
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Das Listener-Objekt muss sich ebenfalls im Spielerinventar befinden,
- ansonsten wird der eingetragene Hook wieder geloescht.
+ /std/player/restrictions.c
-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);
+ARGUMENTE
+=========
- 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;
- }
+ ob - Das Objekt, das informiert werden soll, wenn ein Objekt dem
+ Spielerinventar hinzugefuegt wurde.
-SIEHE AUCH:
- NotifyInsert(), RemoveInsertHook(), QueryInsertHooks()
-----------------------------------------------------------------------------
+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/lfun/obsolete/ModifySkillAttributeOld b/doc/lfun/obsolete/ModifySkillAttributeOld
index 65d9afc..b0b81ab 100644
--- a/doc/lfun/obsolete/ModifySkillAttributeOld
+++ b/doc/lfun/obsolete/ModifySkillAttributeOld
@@ -1,90 +1,118 @@
+
ModifySkillAttributeOld()
+*************************
-FUNKTION:
- varargs int ModifySkillAttributeOld(object caster, string atrname,
- int value, int duration, mixed fun)
-DEFINIERT IN:
- /std/living/skill_attributes.c
+FUNKTION
+========
-ARGUMENTE:
- <caster> IGNORIERT
- frueher Objekt, das die Modifikation vornimmt, heute ist
- dieses Argument ohne Bedeutung und wird ignoriert.
+ varargs int ModifySkillAttributeOld(object caster, string atrname,
+ int value, int duration, mixed fun)
- <atrname> STRING
- Name des zu veraendernden Attributes
- (Definiert in /sys/living/skill_attributes.h)
- <value> INT
- Neuer Wert des Attributs (Standard: 100)
+DEFINIERT IN
+============
- <duration> INT
- Dauer in Sekunden
+ /std/living/skill_attributes.c
- <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!
+ARGUMENTE
+=========
- 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.
+ <caster> IGNORIERT
+ frueher Objekt, das die Modifikation vornimmt, heute ist
+ dieses Argument ohne Bedeutung und wird ignoriert.
- Es sind momentan max. 5 gleichzeitige Skillattribute-Modifikatoren pro SA
- zulaessig.
+ <atrname> STRING
+ Name des zu veraendernden Attributes
+ (Definiert in /sys/living/skill_attributes.h)
-RUECKGABEWERT:
- 0 wenn der Wert ungueltig ist oder aus sonstigem Grunde nicht gesetzt
- werden konnte (fuer bessere Diagnostik -> ModifySkillAttribute()).
- >0 wenn alles okay war
+ <value> INT
+ Neuer Wert des Attributs (Standard: 100)
-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.
+ <duration> INT
+ Dauer in Sekunden
-BEISPIELE:
- Ein NPC:
+ <fun> NICHT MEHR UNTERSTUETZT - ModifySkillAttribute() nutzen!!
- 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).
+BESCHREIBUNG
+============
-SIEHE AUCH:
- P_SKILL_ATTRIBUTES, P_SKILL_ATTRIBUTE_OFFSETS,
- ModifySkillAttribute, QuerySkillAttribute(),
- RemoveSkillAttributeModifer(), QuerySkillAttributeModifier()
+ 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/lfun/obsolete/NotifyGiveQuest b/doc/lfun/obsolete/NotifyGiveQuest
index 7e29798..220942b 100644
--- a/doc/lfun/obsolete/NotifyGiveQuest
+++ b/doc/lfun/obsolete/NotifyGiveQuest
@@ -1,37 +1,62 @@
-********************* OBSOLETE LFUN ***********************************
-* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die *
-* Events (siehe "man events"). *
-***********************************************************************
+
+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
-----------------------------------------------------------------------------
+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/lfun/obsolete/NotifyHpChange b/doc/lfun/obsolete/NotifyHpChange
index 6f82b03..3c96222 100644
--- a/doc/lfun/obsolete/NotifyHpChange
+++ b/doc/lfun/obsolete/NotifyHpChange
@@ -1,47 +1,71 @@
-********************* OBSOLETE LFUN ***********************************
-* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die *
-* Hooks (s. /doc/std/hooks). *
-***********************************************************************
+
NotifyHpChange()
+****************
-FUNKTION:
- void NotifyHpChange();
+********************* OBSOLETE LFUN
+*********************************** * Diese Efun bitte nicht mehr
+benutzen, sondern stattdessen die * * Hooks (s. /doc/std/hooks).
+* *******************************************************************
+**** NotifyHpChange()
-DEFINIERT IN:
- /std/player/life.c
-ARGUMENTE:
- keine
+FUNKTION
+========
-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()!
+ void NotifyHpChange();
-RUeCKGABEWERT:
- keiner
-BEISPIELE:
- ist in Arbeit
+DEFINIERT IN
+============
-SIEHE AUCH:
- P_HP, P_HP_HOOKS, AddHpHook(), RemoveHpHook(),
- Defend(), do_damage(), NotifyPlayerDeath()
+ /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/lfun/obsolete/QueryEnemy b/doc/lfun/obsolete/QueryEnemy
index bf0b583..2613f53 100644
--- a/doc/lfun/obsolete/QueryEnemy
+++ b/doc/lfun/obsolete/QueryEnemy
@@ -1,24 +1,51 @@
-********************* OBSOLETE LFUN ***********************************
-FUNKTION:
- object QueryEnemy();
-DEFINIERT IN:
- /std/living/combat.c
+QueryEnemy()
+************
-ARGUMENTE:
- keine
+********************* OBSOLETE LFUN
+***********************************
-RUeCKGABEWERT:
- gefundener Gegner
-BESCHREIBUNG:
- Diese Funktion liefert zufaellig einen der anwesenden Gegner
- zurueck, sofern keine Gegner bevorzugt ausgewaehlt werden.
+FUNKTION
+========
-BEMERKUNGEN:
- Diese Lfun existiert nicht mehr. Bitte SelectEnemy() benutzen.
+ object QueryEnemy();
-SIEHE AUCH:
- SelectEnemy(), QueryPreferedEnemy(), P_PREFERED_ENEMY
-----------------------------------------------------------------------------
+
+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/lfun/obsolete/QueryInsertHooks b/doc/lfun/obsolete/QueryInsertHooks
index c43d036..317104c 100644
--- a/doc/lfun/obsolete/QueryInsertHooks
+++ b/doc/lfun/obsolete/QueryInsertHooks
@@ -1,31 +1,52 @@
-********************* OBSOLETE LFUN ***********************************
-* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die *
-* Hooks (s. /doc/std/hooks). *
-***********************************************************************
+
QueryInsertHooks()
+******************
-FUNKTION:
- object *QueryInsertHooks();
+********************* OBSOLETE LFUN
+*********************************** * Diese Efun bitte nicht mehr
+benutzen, sondern stattdessen die * * Hooks (s. /doc/std/hooks).
+* *******************************************************************
+**** QueryInsertHooks()
-DEFINIERT IN:
- /std/player/restrictions.c
-ARGUMENTE:
- keine
+FUNKTION
+========
-BESCHREIBUNG:
- (Diese Funktionalitaet wurde ersetzt durch den allgemeinen Hook
- H_HOOK_INSERT und ist nur noch aus Gruenden der Kompatibilitaet
- vorhanden.)
+ object *QueryInsertHooks();
- Diese Funktion gibt die aktuell beim Spielerobjekt angemeldeten
- Listener-Objekte zurueck.
-RUeCKGABEWERT:
- Array aus Objektpointern oder leeres Array
+DEFINIERT IN
+============
-SIEHE AUCH:
- NotifyInsert(), AddInsertHook(), RemoveInsertHook()
+ /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/lfun/obsolete/QueryOptQP b/doc/lfun/obsolete/QueryOptQP
index f6f72c5..77404ad 100644
--- a/doc/lfun/obsolete/QueryOptQP
+++ b/doc/lfun/obsolete/QueryOptQP
@@ -1,25 +1,43 @@
+
QueryOptQP()
+************
-FUNKTION:
- int QueryOptQP()
-DEFINIERT IN:
- /secure/questmaster.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ int QueryOptQP()
-RUECKGABEWERT:
- Abenteuerpunkte der optionalen Quests
-BESCHREIBUNG:
- Diese Funktion liefert die Abenteuerpunkte der optionalen
- Abenteuer zurueck.
+DEFINIERT IN
+============
-SIEHE AUCH:
- GiveQuest, QueryQuest, /secure/questmaster.h, QueryGroupedKeys,
- QueryMaxQP, QueryTotalQP
+ /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/lfun/obsolete/RemoveHpHook b/doc/lfun/obsolete/RemoveHpHook
index d3177f1..54c93ec 100644
--- a/doc/lfun/obsolete/RemoveHpHook
+++ b/doc/lfun/obsolete/RemoveHpHook
@@ -1,25 +1,48 @@
-********************* 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
+********************* OBSOLETE LFUN
+*********************************** * Diese Efun bitte nicht mehr
+benutzen, sondern stattdessen die * * Hooks (s. /doc/std/hooks).
+* *******************************************************************
+**** RemoveHpHook()
-ARGUMENTE:
- ob - das Objekt, das sich austragen moechte.
-BESCHREIBUNG:
- Entfernt den Eintrag fuer dieses Objekt in P_HP_HOOKS.
+FUNKTION
+========
-RUECKGABEWERT:
- 1, wenn Erfolg, 0 sonst
+ int RemoveHpHook(object ob)
-SIEHE AUCH:
- Gegenpart: AddHpHook()
- Props: P_HP_HOOKS, P_HP
+
+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/lfun/obsolete/RemoveInsertHook b/doc/lfun/obsolete/RemoveInsertHook
index f232eed..6c77edf 100644
--- a/doc/lfun/obsolete/RemoveInsertHook
+++ b/doc/lfun/obsolete/RemoveInsertHook
@@ -1,31 +1,52 @@
-********************* OBSOLETE LFUN ***********************************
-* Diese Efun bitte nicht mehr benutzen, sondern stattdessen die *
-* Hooks (s. /doc/std/hooks). *
-***********************************************************************
+
RemoveInsertHook()
+******************
-FUNKTION:
- void RemoveInsertHook(object ob);
+********************* OBSOLETE LFUN
+*********************************** * Diese Efun bitte nicht mehr
+benutzen, sondern stattdessen die * * Hooks (s. /doc/std/hooks).
+* *******************************************************************
+**** RemoveInsertHook()
-DEFINIERT IN:
- /std/player/restrictions.c
-ARGUMENTE:
- ob - Das Objekt, das als Listener aus der Liste ausgetragen werden soll
+FUNKTION
+========
-BESCHREIBUNG:
- (Diese Funktionalitaet wurde ersetzt durch den allgemeinen Hook
- H_HOOK_INSERT und ist nur noch aus Gruenden der Kompatibilitaet
- vorhanden.)
+ void RemoveInsertHook(object ob);
- Diese Funktion wird im Spielerobjekt aufgerufen, um ein als Listener
- eingetragenes Hook-Objekt ob wieder auszutragen.
-RUeCKGABEWERT:
- keiner
+DEFINIERT IN
+============
-SIEHE AUCH:
- NotifyInsert(), AddInsertHook(), QueryInsertHooks()
+ /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/lfun/obsolete/TestAttributeLock b/doc/lfun/obsolete/TestAttributeLock
index 126e931..3d5d54d 100644
--- a/doc/lfun/obsolete/TestAttributeLock
+++ b/doc/lfun/obsolete/TestAttributeLock
@@ -1,25 +1,47 @@
-********************* OBSOLETE LFUN ***********************************
+
TestAttributeLock()
-FUNKTION:
- string TestAttributeLock(mapping check)
+*******************
-DEFINIERT IN:
- /std/living/attributes.c
-
-PARAMETER:
- check - Mapping mit Attributen: ([<attr>:<wert>])
+********************* OBSOLETE LFUN
+*********************************** TestAttributeLock()
-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
+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/lfun/obsolete/extra_look b/doc/lfun/obsolete/extra_look
index 753a8ed..d8e9703 100644
--- a/doc/lfun/obsolete/extra_look
+++ b/doc/lfun/obsolete/extra_look
@@ -1,19 +1,32 @@
-********************* VERALTETE LFUN ******************************
-* Diese LFUN ist veraltet. Bitte benutzt sie NICHT mehr, sondern *
-* stattdessden AddExtraLook(). *
+
+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.
+FUNKTION
+========
-SIEHE AUCH:
- AddExtraLook()
+ 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/lfun/obsolete/paramove b/doc/lfun/obsolete/paramove
index 96686a2..25ce252 100644
--- a/doc/lfun/obsolete/paramove
+++ b/doc/lfun/obsolete/paramove
@@ -1,45 +1,66 @@
-****************************************************************************
-************************* VERALTETE LFUN ***********************************
-************************* DO NOT USE! ***********************************
-****************************************************************************
+
paramove()
+**********
-FUNKTION:
- int paramove();
-DEFINIERT IN:
- /std/room/para.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ int paramove();
-BESCHREIBUNG:
- Bewegt den Spieler ggf. in eine Paralleldimension.
-RUeCKGABEWERT:
- 1, wenn der Spieler die Dimension gewechselt hat.
+DEFINIERT IN
+============
-BEISPIEL:
- init(){
- if(!paramove()) ::init();
- }
+ /std/room/para.c
-BEMERKUNGEN:
- DIESE FUNKTION NICHT MEHR BENUTZEN!
- Diese Funktion sollte nur aus einem init() aufgerufen werden!
+ARGUMENTE
+=========
- 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.
+ keine
- Deswegen ist paramove() veraltet und sollte nicht mehr genutzt werden.
-SIEHE AUCH:
- /std/room/para.c, P_PARA, P_NO_PLAYERS, move
+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/lfun/pick b/doc/lfun/pick
index 59bf51f..5063ee6 100644
--- a/doc/lfun/pick
+++ b/doc/lfun/pick
@@ -1,48 +1,73 @@
+
pick()
+******
-FUNKTION:
- public varargs int pick(object o, mixed msg);
-DEFINIERT IN:
- /std/living/put_and_get.c
+FUNKTION
+========
-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.
+ public varargs int pick(object o, mixed msg);
-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.
+DEFINIERT IN
+============
-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.
+ /std/living/put_and_get.c
- 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);
+ARGUMENTE
+=========
- if (this_player()->pick(ob, ({ "Du nimmst @WENU2 aus dem Regal.",
- "@WER1 nimmt @WENU2 aus dem Regal." })))
- weingummi--;
- else
- ob->remove();
+ 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.
-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
-----------------------------------------------------------------------------
+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/lfun/pick_obj b/doc/lfun/pick_obj
index a4c7c17..6557cee 100644
--- a/doc/lfun/pick_obj
+++ b/doc/lfun/pick_obj
@@ -1,27 +1,43 @@
+
pick_obj()
+**********
+
FUNKTION
- int pick_obj(object ob)
+========
-DEFINIERT IN:
+ int pick_obj(object ob)
- /std/living/put_and_get.c
-ARGUMENTE:
+DEFINIERT IN
+============
- ob Das Objekt, das genommen werden soll.
+ /std/living/put_and_get.c
-BESCHREIBUNG:
- Das Lebewesen, in dem diese Funktion aufgerufen werden soll, hebt
- den angegebenen Gegenstand (ob) auf, falls es ihm moeglich ist.
+ARGUMENTE
+=========
-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
+ ob Das Objekt, das genommen werden soll.
-SIEHE AUCH:
- drop_obj(), find_obs(), give_obj(), put_obj(), /std/living/put_and_get.c
+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/lfun/pick_objects b/doc/lfun/pick_objects
index 92c083d..ac70415 100644
--- a/doc/lfun/pick_objects
+++ b/doc/lfun/pick_objects
@@ -1,39 +1,61 @@
+
pick_objects()
+**************
-FUNKTION:
- public varargs int pick_objects(string str, int flag, mixed msg);
-DEFINIERT IN:
- /std/living/put_and_get.c
+FUNKTION
+========
-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.
+ public varargs int pick_objects(string str, int flag, mixed msg);
-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.
+DEFINIERT IN
+============
-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.
+ /std/living/put_and_get.c
-SIEHE AUCH:
- move(L), pick(L), P_PICK_MSG, find_objects(L), moved_objects(L)
-----------------------------------------------------------------------------
+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/lfun/present_objects b/doc/lfun/present_objects
index 15cf4be..77f31fa 100644
--- a/doc/lfun/present_objects
+++ b/doc/lfun/present_objects
@@ -1,32 +1,50 @@
+
present_objects()
+*****************
-FUNKTION:
- object *present_objects(string desc);
-DEFINIERT IN:
- /std/container/restrictions.c
+FUNKTION
+========
-ARGUMENTE:
- desc
- Umschreibung des gesuchten Objektes oder "alles" oder "alle".
+ object *present_objects(string desc);
-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.
+DEFINIERT IN
+============
- Befindet sich kein Objekt im Behaelter, das sich durch desc ansprechen
- laesst, so wird ein leeres Array zurueckgegeben.
+ /std/container/restrictions.c
-SIEHE AUCH:
- locate_objects(), /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/lfun/put b/doc/lfun/put
index 33e7eaf..9b1d5eb 100644
--- a/doc/lfun/put
+++ b/doc/lfun/put
@@ -1,43 +1,65 @@
+
put()
+*****
-FUNKTION:
- public varargs int put(object o, object dest, mixed msg);
-DEFINIERT IN:
- /std/living/put_and_get.c
+FUNKTION
+========
-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.
+ public varargs int put(object o, object dest, mixed msg);
-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.
+DEFINIERT IN
+============
-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.
+ /std/living/put_and_get.c
- 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
+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/lfun/put_obj b/doc/lfun/put_obj
index 1f1b299..ff4dd91 100644
--- a/doc/lfun/put_obj
+++ b/doc/lfun/put_obj
@@ -1,30 +1,46 @@
+
put_obj()
+*********
+
FUNKTION
- int put_obj(object ob, object where)
+========
-DEFINIERT IN:
+ int put_obj(object ob, object where)
- /std/living/put_and_get.c
-ARGUMENTE:
+DEFINIERT IN
+============
- ob Das Objekt, das irgendwo hineingelegt werden soll.
- where Das (tote) Objekt, in das etwas hineingelegt werden soll.
+ /std/living/put_and_get.c
-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().
+ARGUMENTE
+=========
-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
+ ob Das Objekt, das irgendwo hineingelegt werden soll.
+ where Das (tote) Objekt, in das etwas hineingelegt werden soll.
-SIEHE AUCH:
- drop_obj(), find_obs(), give_obj(), pick_obj(), /std/living/put_and_get.c
+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/lfun/query_prevent_shadow b/doc/lfun/query_prevent_shadow
index 80b0c7d..2c8d2f3 100644
--- a/doc/lfun/query_prevent_shadow
+++ b/doc/lfun/query_prevent_shadow
@@ -1,34 +1,54 @@
+
+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.
+FUNKTION
+========
- Gibt die Funktion 0 zurueck, wird ein Shadow auf das Objekt erlaubt,
- sonst schlaegt es fehl.
+ varargs int query_prevent_shadow(object shadower)
-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;
- }
+PARAMETER
+=========
-SIEHE AUCH:
- Rechte: query_allow_shadow(M)
- Generell: shadow(E), unshadow(E)
- Informationen: query_shadowing(E)
+ object shadower - da Objekt, das eine Beschattung beantragt
-20. Mai 2004 Gloinson
\ No newline at end of file
+
+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/lfun/query_real_name b/doc/lfun/query_real_name
index d7633de..1ebc69f 100644
--- a/doc/lfun/query_real_name
+++ b/doc/lfun/query_real_name
@@ -1,15 +1,26 @@
+
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().
+SYNOPSIS
+========
- 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.
+ string query_real_name(void)
-SEE ALSO:
- shout(E), wizlist(E)
+
+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/lfun/query_weight_contents b/doc/lfun/query_weight_contents
index 13980f8..bd644f5 100644
--- a/doc/lfun/query_weight_contents
+++ b/doc/lfun/query_weight_contents
@@ -1,20 +1,36 @@
+
query_weight_contents()
+***********************
-FUNKTION:
- int query_weight_contents()
-DEFINIERT IN:
- /std/container/restrictions.c
+FUNKTION
+========
-ARGUMENTE:
- keine
+ int query_weight_contents()
-BESCHREIBUNG:
- Gibt das Gewicht des Inhaltes des Behaelters zurueck (ohne
- Beruecksichtigung von P_WEIGHT_PERCENT!)
-RUeCKGABEWERT:
- Das Gewicht des Behaelterinhaltes.
+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/lfun/reduce_hit_points b/doc/lfun/reduce_hit_points
index 39b3368..7a1dcf0 100644
--- a/doc/lfun/reduce_hit_points
+++ b/doc/lfun/reduce_hit_points
@@ -1,43 +1,69 @@
+
reduce_hit_points()
-FUNKTION:
- int reduce_hit_points(int damage)
+*******************
-DEFINIERT IN:
- /std/living/life.c
-ARGUMENTE:
- int damage - der zugefuegte Schaden
+FUNKTION
+========
-BESCHREIBUNG:
- Dem Lebewesen werden damage Lebenspunkte abgezogen, aber der
- Wert wird hinterher nicht kleiner als 1 sein und das Lebewesen
- wird dadurch nicht sterben.
+ int reduce_hit_points(int damage)
-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)
+DEFINIERT IN
+============
-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.
+ /std/living/life.c
- 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
+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/lfun/reduce_spell_points b/doc/lfun/reduce_spell_points
index 13c0630..cddb7da 100644
--- a/doc/lfun/reduce_spell_points
+++ b/doc/lfun/reduce_spell_points
@@ -1,27 +1,48 @@
+
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.
+FUNKTION
+========
-BESCHREIBUNG:
- Dem Lebewesen werden points Konzentrationspunkte abgezogen. Falls
- das Lebewesen weniger Konzentrationspunkte hat, als abgezogen werden
- sollen, werden sie auf 0 gesetzt.
+ void reduce_spell_points(int points)
-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
+DEFINIERT IN
+============
-23.Feb.2004 Gloinson
\ No newline at end of file
+ /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/lfun/register_modifier b/doc/lfun/register_modifier
index 359a050..afe086c 100644
--- a/doc/lfun/register_modifier
+++ b/doc/lfun/register_modifier
@@ -1,24 +1,42 @@
+
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.
+FUNKTION
+========
-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
+ void register_modifier(object modifier)
-13.Jun.2004, Muadib
\ No newline at end of file
+
+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/lfun/remove b/doc/lfun/remove
index 21fc59a..914c1e1 100644
--- a/doc/lfun/remove
+++ b/doc/lfun/remove
@@ -1,34 +1,56 @@
+
remove()
+********
-FUNKTION:
- varargs int remove(int silent);
-DEFINIERT IN:
- /std/thing/moving.c
- /std/living/moving.c
- /std/room/moving.c
+FUNKTION
+========
-ARGUMENTE:
- silent
- Falls ungleich 0, so werden beim Zerstoeren keine Meldungen
- ausgegeben.
+ varargs int remove(int silent);
-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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Nach einem erfolgreichen ::remove() gelten die selben Einschraenkungen
- wie nach einem destruct()!
+ /std/thing/moving.c
+ /std/living/moving.c
+ /std/room/moving.c
-SIEHE AUCH:
- destruct()
-----------------------------------------------------------------------------
+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/lfun/remove_multiple b/doc/lfun/remove_multiple
index 6340fd1..9e60d55 100644
--- a/doc/lfun/remove_multiple
+++ b/doc/lfun/remove_multiple
@@ -1,58 +1,86 @@
+
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.
+FUNKTION
+========
-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.
+ public varargs int remove_multiple(int limit, mixed fun);
- 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).
+DEFINIERT IN
+============
-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");
+ /std/container/items.c
- 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()
+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/lfun/reset b/doc/lfun/reset
index 07a22ee..5959b3f 100644
--- a/doc/lfun/reset
+++ b/doc/lfun/reset
@@ -1,88 +1,106 @@
+
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).
+FUNKTION
+========
- 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().
+ void reset();
+ protected void 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.
+BESCHREIBUNG
+============
- Aendern laesst sich die Zeit zwischen den Aufrufen von reset() mit
- set_next_reset(). Die Aufloesung von 2s kann man nicht aendern.
+ 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 ...
-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();
- ...
+ 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;
}
-
-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);
- }
- }
+ ::create();
+ ...
}
- // 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
+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);
+ }
}
+ }
-SIEHE AUCH:
- clean_up(), set_next_reset(E), query_next_reset(E)
- memory
+ // 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/lfun/restore_hit_points b/doc/lfun/restore_hit_points
index 7ae3457..b4917cf 100644
--- a/doc/lfun/restore_hit_points
+++ b/doc/lfun/restore_hit_points
@@ -1,33 +1,57 @@
+
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.
+FUNKTION
+========
-RUECKGABEWERT:
- Die verbleibenden Lebenspunkte.
+ int restore_hit_points(int heal)
-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!
+ARGUMENTE
+=========
-SIEHE AUCH:
- Gegenpart: reduce_hit_points()
- Verwandt: buffer_hp(), heal_self(), restore_spell_points()
- Props: P_HP
- Konzept: heilung
+ int heal - der zu heilende Betrag
-23.Feb.2004 Gloinson
\ No newline at end of file
+
+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/lfun/restore_spell_points b/doc/lfun/restore_spell_points
index 87c2a6c..2c8e42c 100644
--- a/doc/lfun/restore_spell_points
+++ b/doc/lfun/restore_spell_points
@@ -1,37 +1,61 @@
+
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.
+FUNKTION
+========
-RUECKGABEWERT:
- Keiner
+ void restore_spell_points(int points)
-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.
+ARGUMENTE
+=========
- 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!
+ points: Anzahl der Konzentrationspunkte die gutgeschrieben werden sollen.
-SIEHE AUCH:
- Gegenpart: reduce_spell_points(L)
- Verwandt: buffer_sp(L), restore_hit_points(L)
- Props: P_SP
- Konzept: heilung
-23.Feb.2004 Gloinson
\ No newline at end of file
+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/lfun/save_me b/doc/lfun/save_me
index d7f9e0a..cbce90a 100644
--- a/doc/lfun/save_me
+++ b/doc/lfun/save_me
@@ -1,21 +1,41 @@
+
+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.
+FUNKTION
+========
-BESCHREIBUNG:
- Speichert einen Spieler, seine Autoloader, bestimmt sein GuildRating
- und berechnet/speichert auf Anforderung den Wert der getragenen
- Gegenstaende.
+ void save_me(mixed value_items)
-SIEHE AUCH:
- Props: P_CARRIED_VALUE, P_AUTOLOADOBJ, P_LAST_LOGOUT
- Kommandos: save, ende
+
+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/lfun/second_life b/doc/lfun/second_life
index b5abfd5..1c3fc8b 100644
--- a/doc/lfun/second_life
+++ b/doc/lfun/second_life
@@ -1,30 +1,52 @@
+
second_life()
+*************
-FUNKTION:
- varargs int second_life(object obj);
-DEFINIERT IN:
- /std/player/life.c
+FUNKTION
+========
-ARGUMENTE:
- obj
- Leiche des Lebewesens.
+ varargs int second_life(object obj);
-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
+DEFINIERT IN
+============
-BEMERKUNG:
- Bei NPCs sollte man direkt die() ueberschreiben, wenn man nicht
- moechte, dass sie sterben.
+ /std/player/life.c
-SIEHE AUCH:
- die()
-----------------------------------------------------------------------------
-Last modified: 2015-Jan-19, Arathorn
+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/lfun/sell_obj b/doc/lfun/sell_obj
index 8c362f1..580fd87 100644
--- a/doc/lfun/sell_obj
+++ b/doc/lfun/sell_obj
@@ -1,52 +1,59 @@
-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
+
+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/lfun/set_object_next_reset b/doc/lfun/set_object_next_reset
index 68dfa2f..9b77a9e 100644
--- a/doc/lfun/set_object_next_reset
+++ b/doc/lfun/set_object_next_reset
@@ -1,25 +1,41 @@
-set_object_next_reset()
-FUNKTION:
- int set_object_next_reset(object ob, int zeit );
+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.
+ARGUMENTE
+=========
- Die Benutzung ist nur fuer EM+ moeglich.
+ ob: Das Objekt, dess Reset gesetzt werden soll.
+ zeit: Zeit bis zum naechsten Reset von ob.
-RUECKGABEWERT:
- Gibt den Rueckgabewert des set_next_reset()-Aufrufs in <ob> zurueck.
-SIEHE AUCH:
- set_next_reset(E)
+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/lfun/shoot_dam b/doc/lfun/shoot_dam
index 5d82d02..f66be19 100644
--- a/doc/lfun/shoot_dam
+++ b/doc/lfun/shoot_dam
@@ -1,40 +1,63 @@
+
shoot_dam()
+***********
-FUNKTION:
- static int shoot_dam(mapping shoot)
-DEFINIERT IN:
- /std/ranged_weapon.c
+FUNKTION
+========
-ARGUMENTE:
- mapping shoot - Schussdaten
+ static int shoot_dam(mapping shoot)
-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.
+DEFINIERT IN
+============
-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
+ /std/ranged_weapon.c
-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
\ No newline at end of file
+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/lfun/short b/doc/lfun/short
index a9734c2..f7bb169 100644
--- a/doc/lfun/short
+++ b/doc/lfun/short
@@ -1,31 +1,53 @@
+
short()
-FUNKTION:
- public varargs string short();
+*******
-DEFINIERT IN:
- /std/thing/description.c
-ARGUMENTE:
- keine
+FUNKTION
+========
-BESCHREIBUNG:
- Der Inhalt der Property P_SHORT wird ausgewertet, mit ".\n"
- abgeschlossen und zurueckgegeben.
+ public varargs string short();
-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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- Aehnliches: long()
- Properties: P_SHORT, P_INVIS
- Sonstiges: make_invlist()
+ /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/lfun/show_notify b/doc/lfun/show_notify
index ae09adc..0ce99ac 100644
--- a/doc/lfun/show_notify
+++ b/doc/lfun/show_notify
@@ -1,44 +1,73 @@
+
+show_notify()
+*************
+
give_notify()
-FUNKTION:
- void show_notify(object obj)
-DEFINIERT IN:
- /std/living/put_and_get.c
-ARGUMENTE:
- obj - dem Lebewesen gezeigtes Objekt
+FUNKTION
+========
-RUeCKGABEWERT:
- keiner
+ void show_notify(object obj)
-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:
+DEFINIERT IN
+============
- void quest_ok(object obj) { ...
- // z.B. Vernichtung des Questobjektes und Questtexte
- // Questbelohnung und Questanerkennung, etc.
- }
+ /std/living/put_and_get.c
- 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.
+ARGUMENTE
+=========
-SIEHE AUCH:
- give_notify(), /std/npc/put_and_get.c, /std/living/put_and_get.c
+ 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/lfun/spellbook/AddSpell b/doc/lfun/spellbook/AddSpell
index 78686d1..65f0df8 100644
--- a/doc/lfun/spellbook/AddSpell
+++ b/doc/lfun/spellbook/AddSpell
@@ -1,54 +1,78 @@
+
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
+FUNKTION
+========
-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.
+ varargs int AddSpell(string verb, int kosten, mixed ski)
-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." })
- })])
- ]));
+DEFINIERT IN
+============
-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
+ /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/lfun/spellbook/Erfolg b/doc/lfun/spellbook/Erfolg
index 625bf4f..6338e6d 100644
--- a/doc/lfun/spellbook/Erfolg
+++ b/doc/lfun/spellbook/Erfolg
@@ -1,28 +1,46 @@
+
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
+FUNKTION
+========
-BESCHREIBUNG:
- Wird bei Erfolg eines Spells gerufen. Ruft SpellInform() am
- Environment.
+ void Erfolg(object caster, string spell, mapping sinfo)
-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
\ No newline at end of file
+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/lfun/spellbook/Learn b/doc/lfun/spellbook/Learn
index 4e2431a..8de112e 100644
--- a/doc/lfun/spellbook/Learn
+++ b/doc/lfun/spellbook/Learn
@@ -1,33 +1,54 @@
+
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
+FUNKTION
+========
-BESCHREIBUNG:
- Diese Funktion wird von der Funktion "Misserfolg" aus dem
- Spellbook aufgerufen. Hier lernt der Spieler den Spruch, der
- nicht geglueckt ist.
+ void Learn(object caster, string spell, mapping sinfo)
-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
+DEFINIERT IN
+============
-5. Okt 2011 Gloinson
\ No newline at end of file
+ /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/lfun/spellbook/Misserfolg b/doc/lfun/spellbook/Misserfolg
index 7ad530b..5ffe8de 100644
--- a/doc/lfun/spellbook/Misserfolg
+++ b/doc/lfun/spellbook/Misserfolg
@@ -1,53 +1,78 @@
+
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
+FUNKTION
+========
-BESCHREIBUNG:
- Wird bei Misserfolg eines Spells im Spellbook aufgerufen und
- ruft die Lernfunktion Learn() nach einer Fehlermeldung.
-
- Kann ueberschrieben werden, um die Meldungen anzupassen.
+ void Misserfolg(object caster, string spell, mapping sinfo)
-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
+DEFINIERT IN
+============
-5. Okt 2011 Gloinson
\ No newline at end of file
+ /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/lfun/spellbook/QuerySpell b/doc/lfun/spellbook/QuerySpell
index 0cadec2..963d30c 100644
--- a/doc/lfun/spellbook/QuerySpell
+++ b/doc/lfun/spellbook/QuerySpell
@@ -1,26 +1,46 @@
+
QuerySpell()
-FUNKTION:
- mapping QuerySpell(string spell)
+************
-DEFINIERT IN:
- /std/spellbook.c
-ARGUMENTE:
- string spell Name des Spells
+FUNKTION
+========
-BESCHREIBUNG:
- Gibt das Spellmapping aus P_SB_SPELLS fuer diesen Spell zurueck.
-
- Hier enthaelt QuerySpell nur die Spellbook-Informationen.
+ mapping QuerySpell(string spell)
-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
\ No newline at end of file
+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/lfun/spellbook/SpellSuccess b/doc/lfun/spellbook/SpellSuccess
index ec44884..564c948 100644
--- a/doc/lfun/spellbook/SpellSuccess
+++ b/doc/lfun/spellbook/SpellSuccess
@@ -1,31 +1,52 @@
+
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
+FUNKTION
+========
-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.
+ int SpellSuccess(object caster, mapping sinfo)
-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
+DEFINIERT IN
+============
-5. Okt 2011 Gloinson
\ No newline at end of file
+ /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/lfun/spellbook/TryAttackSpell b/doc/lfun/spellbook/TryAttackSpell
index 76d75b8..d66684e 100644
--- a/doc/lfun/spellbook/TryAttackSpell
+++ b/doc/lfun/spellbook/TryAttackSpell
@@ -1,48 +1,57 @@
-** 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:
+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)
+ mixed is_spell, object caster, mapping sinfo)
-ARGUMENTE:
+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
+ 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:
+BESCHREIBUNG
+============
- Diese Funktion wird vom Spellbook aufgerufen, wenn der Spieler
- einen Angriffsspell gemacht hat und damit Schaden anrichten will.
+ Diese Funktion wird vom Spellbook aufgerufen, wenn der Spieler
+ einen Angriffsspell gemacht hat und damit Schaden anrichten will.
-RUECKGABEWERT:
+RUECKGABEWERT
+=============
- Der Wert, der vom Defend() des Gegners zurueckgeliefert wird.
+ Der Wert, der vom Defend() des Gegners zurueckgeliefert wird.
-BEMERKUNGEN:
+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.
-
+ 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/lfun/trigger_sensitive_attack b/doc/lfun/trigger_sensitive_attack
index 129b38c..f290fc8 100644
--- a/doc/lfun/trigger_sensitive_attack
+++ b/doc/lfun/trigger_sensitive_attack
@@ -1,75 +1,97 @@
+
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
+FUNKTION
+========
-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.
+ varargs void trigger_sensitive_attack(object enemy, string key, int
+ dam, mixed spell, mixed *options);
-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
+DEFINIERT IN
+============
-BEISPIELE:
- Eine Fackel, die sich bei Feuerattacken selbst entzuendet und bei
- Wasserattacken verloescht, koennte man wie folgt implementieren:
+ eigenen sensitiven Objekten, wird aufgerufen von
+ /std/living/inventory.c
- inherit "/std/lightsource.c"
- #include <properties.h>
- #include <sensitive.h>
- #include <combat.h>
+ARGUMENTE
+=========
- create()
- {
- ::create();
+ 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.
- SetProp(...); // die ueblichen Eigenschaften definieren
- SetProp(P_SENSITIVE,
- // Ereignis Key Grenze (keine Optionen)
- ({ ({ SENSITIVE_ATTACK, DT_FIRE, 100 }),
- ({ SENSITIVE_ATTACK, DT_WATER, 100 }) }) );
+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");
}
-
- 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");
- }
+ 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
-----------------------------------------------------------------------------
+SIEHE AUCH
+==========
+
+ trigger_sensitive_inv(), sensitive Objekte
+
Last modified: Sun May 19 15:56:25 1996 by Wargon
diff --git a/doc/lfun/trigger_sensitive_inv b/doc/lfun/trigger_sensitive_inv
index a417ebe..27e26fb 100644
--- a/doc/lfun/trigger_sensitive_inv
+++ b/doc/lfun/trigger_sensitive_inv
@@ -1,40 +1,61 @@
+
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
+FUNKTION
+========
-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.
+ varargs void trigger_sensitive_inv(object ob, string key, int wert,
+ mixed *optionen1, mixed *optionen2);
-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.
+DEFINIERT IN
+============
-RUeCKGABEWERT:
- keiner
+ eigenen Objekten, wird aufgerufen von /std/container/inventory.c
-BEISPIELE:
-SIEHE AUCH:
- trigger_sensitive_attack(), sensitive Objekte
+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/lfun/wield_me b/doc/lfun/wield_me
index 427504e..d1aa842 100644
--- a/doc/lfun/wield_me
+++ b/doc/lfun/wield_me
@@ -1,10 +1,17 @@
+
wield_me()
+**********
-BEMERKUNGEN:
- wield_me wurde durch DoWield ersetzt.
-SIEHE AUCH:
- DoWieldFunc(), /std/weapon.c
+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/lfuns-gilde b/doc/lfuns-gilde
new file mode 100644
index 0000000..b56c734
--- /dev/null
+++ b/doc/lfuns-gilde
@@ -0,0 +1,3 @@
+
+Verzeichnis der lfuns speziell in/für Gilden
+********************************************
diff --git a/doc/lfuns-master b/doc/lfuns-master
new file mode 100644
index 0000000..7ca731d
--- /dev/null
+++ b/doc/lfuns-master
@@ -0,0 +1,13 @@
+
+Verzeichnis der lfuns in master()
+*********************************
+
+* AddWizardForUID()
+
+* QueryUIDAlias()
+
+* QueryUIDsForWizard()
+
+* QueryWizardsForUID()
+
+* RemoveWizardFromUID()
diff --git a/doc/lfuns-obsolet b/doc/lfuns-obsolet
new file mode 100644
index 0000000..ac47c41
--- /dev/null
+++ b/doc/lfuns-obsolet
@@ -0,0 +1,29 @@
+
+Verzeichnis der veralteten lfuns
+********************************
+
+* AddHpHook()
+
+* AddInsertHook()
+
+* ModifySkillAttributeOld()
+
+* NotifyGiveQuest()
+
+* NotifyHpChange()
+
+* QueryEnemy()
+
+* QueryInsertHooks()
+
+* QueryOptQP()
+
+* RemoveHpHook()
+
+* RemoveInsertHook()
+
+* TestAttributeLock()
+
+* extra_look()
+
+* paramove()
diff --git a/doc/make-man.sh b/doc/make-man.sh
index 12f2d03..556f98b 100755
--- a/doc/make-man.sh
+++ b/doc/make-man.sh
@@ -6,8 +6,8 @@
export MRSTDIR=$MDOCDIR/sphinx
export MHTMLDIR=$MDOCDIR/sphinx/_build/html
export MTEXTDIR=$MDOCDIR/sphinx/_build/text
-export MMANDIR=$MDOCDIR/sphinx/man/
-export MANWIDTH=78
+export MMANDIR=$MDOCDIR//
+#export MANWIDTH=78
cd $MRSTDIR
@@ -21,6 +21,6 @@
DIR=`dirname ${FILE}`
BASE=`basename ${FILE} .txt`
mkdir -p ${MMANDIR}/${DIR}
- cp $FILE ${MMANDIR}/${DIR}/${BASE}
+ cp -av $FILE ${MMANDIR}/${DIR}/${BASE}
done
diff --git a/doc/missing b/doc/missing
deleted file mode 100644
index ea65a92..0000000
--- a/doc/missing
+++ /dev/null
@@ -1,8 +0,0 @@
-Fehlende Manpages, die mal geschrieben werden muessten:
-======================================================
-
-* P_MAGIC_RESISTANCE_OFFSET
-* P_DEFUEL_LIMIT_FOOD, P_DEFUEL_LIMIT_DRINK
-* P_DEFUEL_TIME_FOOD, P_DEFUEL_TIME_DRINK
-* P_DEFUEL_AMOUNT_FOOD, P_DEFUEL_AMOUNT_DRINK
-*
diff --git a/doc/props-gilden b/doc/props-gilden
new file mode 100644
index 0000000..df0782d
--- /dev/null
+++ b/doc/props-gilden
@@ -0,0 +1,17 @@
+
+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/props-liste b/doc/props-liste
new file mode 100644
index 0000000..f63a1cf
--- /dev/null
+++ b/doc/props-liste
@@ -0,0 +1,937 @@
+
+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/props-obsolet b/doc/props-obsolet
new file mode 100644
index 0000000..a7e8edd
--- /dev/null
+++ b/doc/props-obsolet
@@ -0,0 +1,29 @@
+
+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/props.index b/doc/props.index
new file mode 100644
index 0000000..b63a77e
--- /dev/null
+++ b/doc/props.index
@@ -0,0 +1,159 @@
+
+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/props/P_ABILITIES b/doc/props/P_ABILITIES
index b82a0f6..b852bdf 100644
--- a/doc/props/P_ABILITIES
+++ b/doc/props/P_ABILITIES
@@ -1,9 +1,22 @@
-NAME:
- P_ABILITIES "abilities"
-DEFINIERT IN:
- /sys/living/attributes.h
+P_ABILITIES
+***********
-BESCHREIBUNG:
- *** OBSOLET! ***
- Siehe P_NEWSKILLS.
+
+NAME
+====
+
+ P_ABILITIES "abilities"
+
+
+DEFINIERT IN
+============
+
+ /sys/living/attributes.h
+
+
+BESCHREIBUNG
+============
+
+ *** OBSOLET! ***
+ Siehe P_NEWSKILLS.
diff --git a/doc/props/P_AC b/doc/props/P_AC
index c62d786..e9eda47 100644
--- a/doc/props/P_AC
+++ b/doc/props/P_AC
@@ -1,28 +1,44 @@
+
P_AC
+****
-NAME:
- P_AC "ac"
-DEFINIERT IN:
- <armour.h>
+NAME
+====
-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.
+ P_AC "ac"
-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
+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/props/P_ACCEPT_PEACE b/doc/props/P_ACCEPT_PEACE
index 07b63a0..214dc06 100644
--- a/doc/props/P_ACCEPT_PEACE
+++ b/doc/props/P_ACCEPT_PEACE
@@ -1,18 +1,37 @@
-PROPERTY
- P_ACCEPT_PEACE "accept_peace"
-DEFINIERT IN
- /sys/combat.h
+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.
+============
+
+ 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
+==========
+
+ QueryPacify(),
+ P_PEACE_HISTORY
+
LETZTE AENDERUNG
+================
+
01.05.2008, Zesstra
diff --git a/doc/props/P_ACHATS b/doc/props/P_ACHATS
index 4097620..c62e357 100644
--- a/doc/props/P_ACHATS
+++ b/doc/props/P_ACHATS
@@ -1,8 +1,21 @@
-NAME:
- P_ACHATS "achats"
-DEFINIERT IN:
- /sys/properties.h
+P_ACHATS
+********
-BESCHREIBUNG:
- Chats, die das Monster im Kampf ausgibt.
+
+NAME
+====
+
+ P_ACHATS "achats"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ Chats, die das Monster im Kampf ausgibt.
diff --git a/doc/props/P_ACHAT_CHANCE b/doc/props/P_ACHAT_CHANCE
index 9ccdf16..fc28ac9 100644
--- a/doc/props/P_ACHAT_CHANCE
+++ b/doc/props/P_ACHAT_CHANCE
@@ -1,8 +1,21 @@
-NAME:
- P_ACHAT_CHANCE "achat_chance"
-DEFINIERT IN:
- /sys/properties.h
+P_ACHAT_CHANCE
+**************
-BESCHREIBUNG:
- Wahrscheinlichkeit fuer die Attack-Chat-Ausgabe.
+
+NAME
+====
+
+ P_ACHAT_CHANCE "achat_chance"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ Wahrscheinlichkeit fuer die Attack-Chat-Ausgabe.
diff --git a/doc/props/P_ACTUAL_NOTIFY_FAIL b/doc/props/P_ACTUAL_NOTIFY_FAIL
index 435a646..0c9acd1 100644
--- a/doc/props/P_ACTUAL_NOTIFY_FAIL
+++ b/doc/props/P_ACTUAL_NOTIFY_FAIL
@@ -1,27 +1,51 @@
-********************** VERALTETE PROPERTY *********************************
-NAME:
- P_ACTUAL_NOTIFY_FAIL "actual_notify_fail"
-DEFINIERT IN:
- /sys/player.h
+P_ACTUAL_NOTIFY_FAIL
+********************
-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.
+********************** VERALTETE PROPERTY
+*********************************
-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.
+NAME
+====
-SIEHE AUCH:
- AddCmd(), add_action()
- notify_fail(), _notify_fail()
+ 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/props/P_ADJECTIVES b/doc/props/P_ADJECTIVES
index 3b44a4f..1c8ccb6 100644
--- a/doc/props/P_ADJECTIVES
+++ b/doc/props/P_ADJECTIVES
@@ -1,22 +1,38 @@
+
P_ADJECTIVES
+************
-NAME:
- P_ADJECTIVES "adjectives"
-DEFINIERT IN:
- <thing/description.h>
+NAME
+====
-BESCHREIBUNG:
- Hier steht ein Array von Strings, welche die Identifizierung des
- Objektes ergaenzen. Die Verwaltung erfolgt ueber die Funktionen
- AddAdjective() und RemoveAdjective().
+ P_ADJECTIVES "adjectives"
-BEMERKUNGEN:
- Man sollte an dieser Property nicht "von Hand" herumfummeln, sondern
- immer die zugehoerigen Funktionen benutzen!
-SIEHE AUCH:
- /std/thing/description.c, AddAdjective(), RemoveAdjective()
+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/props/P_AERIAL_HELPERS b/doc/props/P_AERIAL_HELPERS
index 2606884..781510c 100644
--- a/doc/props/P_AERIAL_HELPERS
+++ b/doc/props/P_AERIAL_HELPERS
@@ -1,45 +1,63 @@
+
P_AERIAL_HELPERS
+****************
-NAME:
- P_AERIAL_HELPERS "lib_p_aerial_helpers"
-DEFINIERT IN:
- <living/helpers.h>
+NAME
+====
-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().
+ P_AERIAL_HELPERS "lib_p_aerial_helpers"
-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:
+DEFINIERT IN
+============
- 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");
- }
+ <living/helpers.h>
-SIEHE AUCH:
- Methoden: RegisterHelperObject(L), UnregisterHelperObject(L)
- Properties: P_HELPER_OBJECTS, P_AQUATIC_HELPERS
-----------------------------------------------------------------------------
+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/props/P_AGE b/doc/props/P_AGE
index ad6388a..e35473c 100644
--- a/doc/props/P_AGE
+++ b/doc/props/P_AGE
@@ -1,8 +1,21 @@
-NAME:
- P_AGE "age"
-DEFINIERT IN:
- /sys/living/life.h
+P_AGE
+*****
-BESCHREIBUNG:
- Alter des Spielers in Heart-Beats (1 HB == 2 Sekunden)
+
+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/props/P_AGGRESSIVE b/doc/props/P_AGGRESSIVE
index b10d97e..5184687 100644
--- a/doc/props/P_AGGRESSIVE
+++ b/doc/props/P_AGGRESSIVE
@@ -1,39 +1,55 @@
-NAME:
- P_AGGRESSIVE "aggressive"
-DEFINIERT IN:
- /sys/properties.h
+P_AGGRESSIVE
+************
-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.
+NAME
+====
- 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.
+ P_AGGRESSIVE "aggressive"
- 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.
+DEFINIERT IN
+============
- 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%.
+ /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/props/P_ALCOHOL b/doc/props/P_ALCOHOL
index 63005b7..d827a94 100644
--- a/doc/props/P_ALCOHOL
+++ b/doc/props/P_ALCOHOL
@@ -1,22 +1,36 @@
-NAME:
- P_ALCOHOL "alcohol"
-DEFINIERT IN:
- /sys/living/life.h
+P_ALCOHOL
+*********
-BESCHREIBUNG:
- - Lebewesen
- Numerischer Wert fuer den Grad der Betrunkenheit eines Lebewesens.
- Der maximale Wert steht in P_MAX_ALCOHOL.
+NAME
+====
- - Speisen/Kneipen
- Numerischer Wert fuer den Grad, den eine Portion der Speise den
- Konsumenten betrunken macht
+ P_ALCOHOL "alcohol"
-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
\ No newline at end of file
+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/props/P_ALCOHOL_DELAY b/doc/props/P_ALCOHOL_DELAY
index 4c6d2c1..6ea0513 100644
--- a/doc/props/P_ALCOHOL_DELAY
+++ b/doc/props/P_ALCOHOL_DELAY
@@ -1,10 +1,23 @@
-NAME:
- P_ALCOHOL_DELAY "alcohol_delay"
-DEFINIERT IN:
- /sys/living/life.h
+P_ALCOHOL_DELAY
+***************
-BESCHREIBUNG:
- Anzahl der heart_beats, bis P_ALCOHOL um einen Punkt sinkt.
- Aenderungen dieser Property in Spielern beduerfen der
- Genehmigung des EM fuer Balance.
+
+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/props/P_ALC_FULL_MSG b/doc/props/P_ALC_FULL_MSG
index bd84a86..5df4b65 100644
--- a/doc/props/P_ALC_FULL_MSG
+++ b/doc/props/P_ALC_FULL_MSG
@@ -1,24 +1,45 @@
-NAME:
- P_ALC_FULL_MSG "std_food_alc_full_msg"
-DEFINIERT IN:
- <sys/food.h>
+P_ALC_FULL_MSG
+**************
-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
+NAME
+====
-------------------------------------------------------------------------------
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
\ No newline at end of file
+ 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/props/P_ALIGN b/doc/props/P_ALIGN
index f1d3465..d4ca76c 100644
--- a/doc/props/P_ALIGN
+++ b/doc/props/P_ALIGN
@@ -1,17 +1,29 @@
-NAME:
- P_ALIGN "align"
-DEFINIERT IN:
- /sys/living/life.h
+P_ALIGN
+*******
-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.
+NAME
+====
- Werte ausserhalb dieser Skala werden zwar teilweise verwendet,
- das Setzen derselben sollte jedoch UNBEDINGT unterbleiben.
+ 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/props/P_ALLOWED_SHADOW b/doc/props/P_ALLOWED_SHADOW
index 39482fd..5d849b7 100644
--- a/doc/props/P_ALLOWED_SHADOW
+++ b/doc/props/P_ALLOWED_SHADOW
@@ -1,24 +1,38 @@
-NAME:
- P_ALLOWED_SHADOW "allowed_shadow"
-DEFINIERT IN:
- /sys/player/base.h
+P_ALLOWED_SHADOW
+****************
-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.
+NAME
+====
-BEMERKUNG:
+ P_ALLOWED_SHADOW "allowed_shadow"
- 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.
-------------------------------------------------------------------------------
+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/props/P_AMMUNITION b/doc/props/P_AMMUNITION
index f8903af..cbe7f56 100644
--- a/doc/props/P_AMMUNITION
+++ b/doc/props/P_AMMUNITION
@@ -1,42 +1,62 @@
+
P_AMMUNITION
+************
-NAME:
- P_AMMUNITION "munition"
-DEFINIERT IN:
- <combat.h>
+NAME
+====
-BESCHREIBUNG:
- Enthaelt die fuer eine Waffe gueltige Munition als String. Die
- Munition muss diesen String als ID besitzen.
+ P_AMMUNITION "munition"
- 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.
+DEFINIERT IN
+============
- Momentan sind vier Munitionsarten in der combat.h vordefiniert:
- MUN_ARROW, MUN_STONE, MUN_BOLT, MUN_MISC
+ <combat.h>
-BEISPIELE:
- // fuer ein kleines Blasrohr im Blasrohr
- SetProp(P_AMMUNITION, MUN_MISC("Erbsen"));
- // Entsprechend in der Munition:
- AddId(MUN_MISC("Erbsen"));
+BESCHREIBUNG
+============
-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
+ Enthaelt die fuer eine Waffe gueltige Munition als String. Die
+ Munition muss diesen String als ID besitzen.
-29.Jul 2014 Gloinson
\ No newline at end of file
+ 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/props/P_AMOUNT b/doc/props/P_AMOUNT
index a44e45a..5c0e51a 100644
--- a/doc/props/P_AMOUNT
+++ b/doc/props/P_AMOUNT
@@ -1,8 +1,21 @@
-NAME:
- P_AMOUNT "amount"
-DEFINIERT IN:
- /sys/properties.h
+P_AMOUNT
+********
-BESCHREIBUNG:
- Anzahl der Objekte, fuer die das Objekt steht.
+
+NAME
+====
+
+ P_AMOUNT "amount"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ Anzahl der Objekte, fuer die das Objekt steht.
diff --git a/doc/props/P_AQUATIC_HELPERS b/doc/props/P_AQUATIC_HELPERS
index 33a07ab..8429a41 100644
--- a/doc/props/P_AQUATIC_HELPERS
+++ b/doc/props/P_AQUATIC_HELPERS
@@ -1,46 +1,64 @@
+
P_AQUATIC_HELPERS
+*****************
-NAME:
- P_AQUATIC_HELPERS "lib_p_aquatic_helpers"
-DEFINIERT IN:
- <living/helpers.h>
+NAME
+====
-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().
+ P_AQUATIC_HELPERS "lib_p_aquatic_helpers"
-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:
+DEFINIERT IN
+============
- 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");
- }
+ <living/helpers.h>
-SIEHE AUCH:
- Methoden: RegisterHelperObject(L), UnregisterHelperObject(L)
- Properties: P_HELPER_OBJECTS, P_AERIAL_HELPERS
-----------------------------------------------------------------------------
+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/props/P_ARMOURS b/doc/props/P_ARMOURS
index 3156bf6..e0d6a0c 100644
--- a/doc/props/P_ARMOURS
+++ b/doc/props/P_ARMOURS
@@ -1,25 +1,41 @@
+
P_ARMOURS
+*********
-NAME:
- P_ARMOURS "armours"
-DEFINIERT IN:
- <living/combat.h>
+NAME
+====
-BESCHREIBUNG:
- Array mit den getragenen Schutzbekleidungen des Lebewesen.
+ P_ARMOURS "armours"
- 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
+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/props/P_ARMOUR_TYPE b/doc/props/P_ARMOUR_TYPE
index 35978f2..19e6812 100644
--- a/doc/props/P_ARMOUR_TYPE
+++ b/doc/props/P_ARMOUR_TYPE
@@ -1,46 +1,63 @@
+
P_ARMOUR_TYPE
+*************
-NAME:
- P_ARMOUR_TYPE "armour_type"
-DEFINIERT IN:
- <armour.h>
+NAME
+====
-BESCHREIBUNG:
- In dieser Property wird der Typ einer Ruestung festgehalten. Man sollte
- hier nur die in <combat.h> definierten Konstanten verwenden:
+ P_ARMOUR_TYPE "armour_type"
- 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.
+DEFINIERT IN
+============
-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.
+ <armour.h>
-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
+
+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/props/P_ARRIVEMSG b/doc/props/P_ARRIVEMSG
index 02d5759..cdafdaa 100644
--- a/doc/props/P_ARRIVEMSG
+++ b/doc/props/P_ARRIVEMSG
@@ -1,8 +1,21 @@
-NAME:
- P_ARRIVEMSG "arrivemsg"
-DEFINIERT IN:
- /sys/transport.h
+P_ARRIVEMSG
+***********
-BESCHREIBUNG:
- Meldung, wenn der Transporter anlegt.
+
+NAME
+====
+
+ P_ARRIVEMSG "arrivemsg"
+
+
+DEFINIERT IN
+============
+
+ /sys/transport.h
+
+
+BESCHREIBUNG
+============
+
+ Meldung, wenn der Transporter anlegt.
diff --git a/doc/props/P_ARTICLE b/doc/props/P_ARTICLE
index 1517865..2bf2c54 100644
--- a/doc/props/P_ARTICLE
+++ b/doc/props/P_ARTICLE
@@ -1,15 +1,28 @@
-NAME:
- P_ARTICLE "article"
-DEFINIERT IN:
- /sys/thing/language.h
+P_ARTICLE
+*********
-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.
\ No newline at end of file
+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/props/P_ATTACK_BUSY b/doc/props/P_ATTACK_BUSY
index b55dc5b..dfc8ba6 100644
--- a/doc/props/P_ATTACK_BUSY
+++ b/doc/props/P_ATTACK_BUSY
@@ -1,44 +1,67 @@
-NAME:
- P_ATTACK_BUSY "attack_busy"
-DEFINIERT IN:
- /sys/living/combat.h
+P_ATTACK_BUSY
+*************
-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)
+NAME
+====
- Das Maximum liegt bei 500.
- Damit betraegt die Anzahl der moeglichen Aktionen pro Runde: Wert/100,
- also maximal 5 Aktionen pro Runde.
+ P_ATTACK_BUSY "attack_busy"
- 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);
+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/props/P_ATTRIBUTES b/doc/props/P_ATTRIBUTES
index 29da911..ed5dd1c 100644
--- a/doc/props/P_ATTRIBUTES
+++ b/doc/props/P_ATTRIBUTES
@@ -1,58 +1,79 @@
-NAME:
- P_ATTRIBUTES "attributes"
-DEFINIERT IN:
- /sys/living/attributes.h
+P_ATTRIBUTES
+************
-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.
+NAME
+====
- 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.
+ P_ATTRIBUTES "attributes"
- 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
+DEFINIERT IN
+============
-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
+ /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/props/P_ATTRIBUTES_MODIFIER b/doc/props/P_ATTRIBUTES_MODIFIER
index f5ba513..ab9f24d 100644
--- a/doc/props/P_ATTRIBUTES_MODIFIER
+++ b/doc/props/P_ATTRIBUTES_MODIFIER
@@ -1,56 +1,78 @@
-NAME:
- P_ATTRIBUTES_MODIFIER "attributes_modifier"
-DEFINIERT IN:
- /sys/living/attributes.h
+P_ATTRIBUTES_MODIFIER
+*********************
-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, ... ]) , ... ])
+NAME
+====
- gespeichert. Das Setzen folg hingegen in der Form
+ P_ATTRIBUTES_MODIFIER "attributes_modifier"
- 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:
+DEFINIERT IN
+============
- #death Attribut-Abzug durch Todesfolgen (Mudlib)
- #drain Statabzug durch NPCs (Paracelsus)
- #frosch Staerken-Abzug bei Froeschen (Mudlib)
+ /sys/living/attributes.h
-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}));
+BESCHREIBUNG
+============
-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
-----------------------------------------------------------------------------
+ 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/props/P_ATTRIBUTES_OFFSETS b/doc/props/P_ATTRIBUTES_OFFSETS
index 3ebe2b7..dfcbb8c 100644
--- a/doc/props/P_ATTRIBUTES_OFFSETS
+++ b/doc/props/P_ATTRIBUTES_OFFSETS
@@ -1,27 +1,46 @@
-NAME:
- P_ATTRIBUTES_OFFSETS "attributes_offsets"
-DEFINIERT IN:
- /sys/living/attributes.h
+P_ATTRIBUTES_OFFSETS
+********************
-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.
+NAME
+====
-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
-----------------------------------------------------------------------------
+ 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/props/P_AUTH_INFO b/doc/props/P_AUTH_INFO
index 5ca65c5..953b519 100644
--- a/doc/props/P_AUTH_INFO
+++ b/doc/props/P_AUTH_INFO
@@ -1,8 +1,21 @@
-NAME:
- P_AUTH_INFO "auth_info"
-DEFINIERT IN:
- /sys/player.h
+P_AUTH_INFO
+***********
-BESCHREIBUNG:
- Username des Spielers, wenn bei ihm ein AUTHD laeuft
+
+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/props/P_AUTOLOAD b/doc/props/P_AUTOLOAD
index 6ea69c9..5e623bb 100644
--- a/doc/props/P_AUTOLOAD
+++ b/doc/props/P_AUTOLOAD
@@ -1,15 +1,31 @@
-NAME:
- P_AUTOLOAD "autoload"
-DEFINIERT IN:
- /sys/player/base.h
+P_AUTOLOAD
+**********
-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)
+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/props/P_AUTOLOADOBJ b/doc/props/P_AUTOLOADOBJ
index 32b433d..3184fff 100644
--- a/doc/props/P_AUTOLOADOBJ
+++ b/doc/props/P_AUTOLOADOBJ
@@ -1,119 +1,141 @@
-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);
- ...
- }
+P_AUTOLOADOBJ
+*************
- ## Variante 2: Speicherung mehrerer Variablen ueber
- ## P_AUTOLOADOBJ (elegante Verwaltung)
+NAME
+====
- // 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;
- }
+ P_AUTOLOADOBJ "autoloadobj"
- ## 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);
+DEFINIERT IN
+============
- void create() {
- // Binden der Methoden
- Set(P_AUTOLOADOBJ, #'my_query_autoloadobj, F_QUERY_METHOD);
- Set(P_AUTOLOADOBJ, #'my_set_autoloadobj, F_SET_METHOD);
+ /sys/player/base.h
- // die werden nur von mir veraendert!
- Set(P_AUTOLOADOBJ, PROTECTED, F_MODE_AS);
- ...
- }
- static mixed *my_query_autoloadobj () {
- // s.o.
- }
+BESCHREIBUNG
+============
- static mixed *my_set_autoloadobj (mixed *new) {
- // s.o.
- }
+ Hiermit kann prinzipiell angegeben werden ob ein Objekt ueber das
+ Ausloggen eines Spielers (Reboot/ende) behalten werden soll.
-SIEHE AUCH:
- P_AUTOLOAD, SetProp
+ 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/props/P_AVATAR_URI b/doc/props/P_AVATAR_URI
index 3275399..0a2437c 100644
--- a/doc/props/P_AVATAR_URI
+++ b/doc/props/P_AVATAR_URI
@@ -1,22 +1,44 @@
-NAME:
- P_AVATAR_URI "p_lib_avataruri"
-DEFINIERT IN:
- /sys/living/description.h
+P_AVATAR_URI
+************
-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.
+NAME
+====
-SIEHE AUCH:
- avatar
+ P_AVATAR_URI "p_lib_avataruri"
-LETZTER AENDERUNG:
- 03.9.2011, Zesstra
+
+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/props/P_AVERAGE_SIZE b/doc/props/P_AVERAGE_SIZE
index 4a61208..155528f 100644
--- a/doc/props/P_AVERAGE_SIZE
+++ b/doc/props/P_AVERAGE_SIZE
@@ -1,8 +1,21 @@
-NAME:
- P_AVERAGE_SIZE "average_size"
-DEFINIERT IN:
- /sys/player/description.h
+P_AVERAGE_SIZE
+**************
-BESCHREIBUNG:
- Durchschnittliche Groesse eines Wesens dieser Rasse (derzeit nur Player)
+
+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/props/P_AVERAGE_WEIGHT b/doc/props/P_AVERAGE_WEIGHT
index 18557cc..d71c53b 100644
--- a/doc/props/P_AVERAGE_WEIGHT
+++ b/doc/props/P_AVERAGE_WEIGHT
@@ -1,8 +1,21 @@
-NAME:
- P_AVERAGE_WEIGHT "average_weight"
-DEFINIERT IN:
- /sys/player/description.h
+P_AVERAGE_WEIGHT
+****************
-BESCHREIBUNG:
- Durchschnittliche Gewicht eines Wesens dieser Rasse (derzeit nur Player)
+
+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/props/P_AWAY b/doc/props/P_AWAY
index ba2c938..5678440 100644
--- a/doc/props/P_AWAY
+++ b/doc/props/P_AWAY
@@ -1,8 +1,21 @@
-NAME:
- P_AWAY "away"
-DEFINIERT IN:
- /sys/properties.h
+P_AWAY
+******
-BESCHREIBUNG:
- String der ausgegeben wird, wenn man weg ist und eine Mitteilung bekommt.
+
+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/props/P_BAD_MSG b/doc/props/P_BAD_MSG
index e067f2a..7015a9c 100644
--- a/doc/props/P_BAD_MSG
+++ b/doc/props/P_BAD_MSG
@@ -1,27 +1,48 @@
-NAME:
- P_BAD_MSG "std_food_bad_msg"
-DEFINIERT IN:
- <sys/food.h>
+P_BAD_MSG
+*********
-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
+NAME
+====
-------------------------------------------------------------------------------
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
\ No newline at end of file
+ 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/props/P_BLIND b/doc/props/P_BLIND
index a80814b..da86624 100644
--- a/doc/props/P_BLIND
+++ b/doc/props/P_BLIND
@@ -1,35 +1,56 @@
-NAME:
- P_BLIND "blind"
-DEFINIERT IN:
- /sys/player/viewcmd.h
+P_BLIND
+*******
-BESCHREIBUNG:
- 1, wenn der Spieler blind ist und nichts mehr sehen kann.
- Wird von CannotSee() bei 'schau' und Betreten von Raeumen
- u.ae. ausgewertet.
+NAME
+====
- P_BLIND kann auch auf einen String gesetzt werden, der
- dann statt des 'Du bist blind' ausgegeben wird.
+ P_BLIND "blind"
-BEISPIELE:
- this_player()->SetProp(P_BLIND,1);
+DEFINIERT IN
+============
- 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)).
+ /sys/player/viewcmd.h
- Denn CannotSee() beruecksichtigt auch Nachtsicht (bzw. hier
- eine nicht aktivierte) und die Lichtmodifikatoren.
-SIEHE AUCH:
- P_LIGHT_MODIFIER, P_PLAYER_LIGHT, CannotSee
+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/props/P_BODY b/doc/props/P_BODY
index 7d04581..5871adb 100644
--- a/doc/props/P_BODY
+++ b/doc/props/P_BODY
@@ -1,9 +1,22 @@
-NAME:
- P_BODY "body"
-DEFINIERT IN:
- /sys/properties.h
+P_BODY
+******
-BESCHREIBUNG:
- Numerischer Wert fuer die Abwehrstaerke des blanken Koerpers
- des Wesens.
+
+NAME
+====
+
+ P_BODY "body"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ Numerischer Wert fuer die Abwehrstaerke des blanken Koerpers
+ des Wesens.
diff --git a/doc/props/P_BRIEF b/doc/props/P_BRIEF
index 33ef486..f6d3769 100644
--- a/doc/props/P_BRIEF
+++ b/doc/props/P_BRIEF
@@ -1,8 +1,21 @@
-NAME:
- P_BRIEF "brief"
-DEFINIERT IN:
- /sys/player/viewcmd.h
+P_BRIEF
+*******
-BESCHREIBUNG:
- Ist gesetzt, wenn der Spieler nur die Kurzbeschreibung sehen will.
+
+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/props/P_BUFFER b/doc/props/P_BUFFER
index 268f719..699f91c 100644
--- a/doc/props/P_BUFFER
+++ b/doc/props/P_BUFFER
@@ -1,9 +1,21 @@
-NAME:
- P_BUFFER "buffer"
-DEFINIERT IN:
- /sys/player/comm.h
+P_BUFFER
+********
-BESCHREIBUNG:
- Zeigt an, ob der Kobold des Spielers aktiv oder nicht aktiv ist.
+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/props/P_BUY_ONLY_PLANTS b/doc/props/P_BUY_ONLY_PLANTS
index 46747c4..0d15a94 100644
--- a/doc/props/P_BUY_ONLY_PLANTS
+++ b/doc/props/P_BUY_ONLY_PLANTS
@@ -1,15 +1,31 @@
-NAME:
- P_BUY_ONLY_PLANTS "lib_p_buy_only_plants"
-DEFINIERT IN:
- /sys/room/description.h
+P_BUY_ONLY_PLANTS
+*****************
-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
+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/props/P_CALLED_FROM_IP b/doc/props/P_CALLED_FROM_IP
index d9427d2..306241c 100644
--- a/doc/props/P_CALLED_FROM_IP
+++ b/doc/props/P_CALLED_FROM_IP
@@ -1,8 +1,21 @@
-NAME:
- P_CALLED_FROM_IP "called_from_ip"
-DEFINIERT IN:
- /sys/properties.h
+P_CALLED_FROM_IP
+****************
-BESCHREIBUNG:
- Letzte IP-Adr, von der aus sich der Spieler eingeloggt hat.
+
+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/props/P_CAN_FLAGS b/doc/props/P_CAN_FLAGS
index ba3eb2a..06afe76 100644
--- a/doc/props/P_CAN_FLAGS
+++ b/doc/props/P_CAN_FLAGS
@@ -1,9 +1,22 @@
-NAME:
- P_CAN_FLAGS "can_flags"
-DEFINIERT IN:
- /sys/player/can.h
+P_CAN_FLAGS
+***********
-BESCHREIBUNG:
- Flags die bestimmte Befehle freischalten:
- CAN_EMOTE, CAN_ECHO, CAN_REMOTE, CAN_PRESAY
+
+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/props/P_CAP_NAME b/doc/props/P_CAP_NAME
index 7fbe408..0069948 100644
--- a/doc/props/P_CAP_NAME
+++ b/doc/props/P_CAP_NAME
@@ -1,9 +1,22 @@
-NAME:
- P_CAP_NAME "cap_name"
-DEFINIERT IN:
- /sys/properties.h
+P_CAP_NAME
+**********
-BESCHREIBUNG:
- Name des Spielers, der dekliniert und ausgegen wird.
- NOT YET IMPLEMENTED.
+
+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/props/P_CARRIED_VALUE b/doc/props/P_CARRIED_VALUE
index 7df9b63..8792664 100644
--- a/doc/props/P_CARRIED_VALUE
+++ b/doc/props/P_CARRIED_VALUE
@@ -1,8 +1,21 @@
-NAME:
- P_CARRIED_VALUE "carried"
-DEFINIERT IN:
- /sys/player/base.h
+P_CARRIED_VALUE
+***************
-BESCHREIBUNG:
- Entschaedigung, die der Spieler beim Einloggen erhaelt.
+
+NAME
+====
+
+ P_CARRIED_VALUE "carried"
+
+
+DEFINIERT IN
+============
+
+ /sys/player/base.h
+
+
+BESCHREIBUNG
+============
+
+ Entschaedigung, die der Spieler beim Einloggen erhaelt.
diff --git a/doc/props/P_CHATS b/doc/props/P_CHATS
index 633cdea..51e1a5e 100644
--- a/doc/props/P_CHATS
+++ b/doc/props/P_CHATS
@@ -1,8 +1,21 @@
-NAME:
- P_CHATS "chats"
-DEFINIERT IN:
- /sys/properties.h
+P_CHATS
+*******
-BESCHREIBUNG:
- Alist mit Strings, die das Monster zufaellig ausgibt.
+
+NAME
+====
+
+ P_CHATS "chats"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ Alist mit Strings, die das Monster zufaellig ausgibt.
diff --git a/doc/props/P_CHAT_CHANCE b/doc/props/P_CHAT_CHANCE
index b6acf08..bd032bf 100644
--- a/doc/props/P_CHAT_CHANCE
+++ b/doc/props/P_CHAT_CHANCE
@@ -1,8 +1,21 @@
-NAME:
- P_CHAT_CHANCE "chat_chance"
-DEFINIERT IN:
- /sys/properties.h
+P_CHAT_CHANCE
+*************
-BESCHREIBUNG:
- Wahrscheinlichkeit, mit der die Chats ausgegeben werden.
+
+NAME
+====
+
+ P_CHAT_CHANCE "chat_chance"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ Wahrscheinlichkeit, mit der die Chats ausgegeben werden.
diff --git a/doc/props/P_CLASS b/doc/props/P_CLASS
index e074394..80017cc 100644
--- a/doc/props/P_CLASS
+++ b/doc/props/P_CLASS
@@ -1,19 +1,33 @@
+
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
+NAME
+====
-SIEHE AUCH:
- AddClass(), RemoveClass(), is_class_member()
+ 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/props/P_CLOCKMSG b/doc/props/P_CLOCKMSG
index 8b72d68..6f85b56 100644
--- a/doc/props/P_CLOCKMSG
+++ b/doc/props/P_CLOCKMSG
@@ -1,8 +1,21 @@
-NAME:
- P_CLOCKMSG "clockmsg"
-DEFINIERT IN:
- /sys/properties.h
+P_CLOCKMSG
+**********
-BESCHREIBUNG:
- Die Meldung wird zur vollen Stunde ausgegeben
+
+NAME
+====
+
+ P_CLOCKMSG "clockmsg"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ Die Meldung wird zur vollen Stunde ausgegeben
diff --git a/doc/props/P_CLONER b/doc/props/P_CLONER
index 659b614..75e9d02 100644
--- a/doc/props/P_CLONER
+++ b/doc/props/P_CLONER
@@ -1,12 +1,28 @@
-NAME:
- P_CLONER "cloner"
-DEFINIERT IN:
- /sys/properties.h
+P_CLONER
+********
-BESCHREIBUNG:
- Enthaelt einen String mit dem Namen desjenigen, der das Objekt gecloned
- hat.
-SIEHE AUCH:
- P_CLONE_TIME
+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/props/P_CLONE_MSG b/doc/props/P_CLONE_MSG
index d9c96a2..d16f42e 100644
--- a/doc/props/P_CLONE_MSG
+++ b/doc/props/P_CLONE_MSG
@@ -1,8 +1,21 @@
-NAME:
- P_CLONE_MSG "clone_msg"
-DEFINIERT IN:
- /sys/player/base.h
+P_CLONE_MSG
+***********
-BESCHREIBUNG:
- Meldung, die beim Clonen eines Obj ausgegegen wird (nur Magier)
+
+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/props/P_CLONE_TIME b/doc/props/P_CLONE_TIME
index a904846..fb7c3e5 100644
--- a/doc/props/P_CLONE_TIME
+++ b/doc/props/P_CLONE_TIME
@@ -1,14 +1,30 @@
-NAME:
- P_CLONE_TIME "clone_time"
-DEFINIERT IN:
- /sys/thing/description.h
+P_CLONE_TIME
+************
-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)
+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/props/P_CLOTHING b/doc/props/P_CLOTHING
index 793f098..3458058 100644
--- a/doc/props/P_CLOTHING
+++ b/doc/props/P_CLOTHING
@@ -1,22 +1,42 @@
+
+P_CLOTHING
+**********
+
+
P_CLOTHINGS
+===========
-NAME:
- P_CLOTHING "std:clothing"
-DEFINIERT IN:
- <living/clothing.h>
+NAME
+====
-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.
+ P_CLOTHING "std:clothing"
- Diese Property kann nur vom Lebewesen selber beschrieben werden.
-
-SIEHE AUCH:
- Verwandt: QueryArmourByType(L), FilterClothing(), FilterArmours()
- Wear(), Unwear(), P_ARMOURS
+
+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/props/P_CMSG b/doc/props/P_CMSG
index 9001722..e38f085 100644
--- a/doc/props/P_CMSG
+++ b/doc/props/P_CMSG
@@ -1,8 +1,21 @@
-NAME:
- P_CMSG "clonemsg"
-DEFINIERT IN:
- /sys/player/base.h
+P_CMSG
+******
-BESCHREIBUNG:
- *** OBSOLET! *** Siehe P_CLONE_MSG
+
+NAME
+====
+
+ P_CMSG "clonemsg"
+
+
+DEFINIERT IN
+============
+
+ /sys/player/base.h
+
+
+BESCHREIBUNG
+============
+
+ *** OBSOLET! *** Siehe P_CLONE_MSG
diff --git a/doc/props/P_CNT_STATUS b/doc/props/P_CNT_STATUS
index cd92324..5bcc584 100644
--- a/doc/props/P_CNT_STATUS
+++ b/doc/props/P_CNT_STATUS
@@ -1,9 +1,22 @@
-NAME:
- P_CNT_STATUS "cnt_status"
-DEFINIERT IN:
- /sys/container.h
+P_CNT_STATUS
+************
-BESCHREIBUNG:
- Status des Containers (offen, geschlossen, abgeschlossen)
- siehe auch /sys/container.h
+
+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/props/P_COMBATCMDS b/doc/props/P_COMBATCMDS
index c29a65f..e82336a 100644
--- a/doc/props/P_COMBATCMDS
+++ b/doc/props/P_COMBATCMDS
@@ -1,31 +1,44 @@
-NAME:
- P_COMBATCMDS "combatcmds"
-DEFINIERT IN:
- /sys/properties.h
+P_COMBATCMDS
+************
-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.
+
+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/props/P_COMMANDS b/doc/props/P_COMMANDS
index d0ff99b..5812b35 100644
--- a/doc/props/P_COMMANDS
+++ b/doc/props/P_COMMANDS
@@ -1,58 +1,76 @@
+
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.
+NAME
+====
- Sie sollte nicht von Hand manipuliert werden, sondern nur ueber die
- Funktionen AddCmd() und RemoveCmd().
+ P_COMMANDS "commands"
- Das Mapping hat folgenden Aufbau:
- ([ befehl : ({funktion1,...});
- ({flag1,...});
- ({regel1,...});
- ({id1, ...}),
- ({closure auf fun1, ...}),
- ... ])
+DEFINIERT IN
+============
- Die Eintraege entsprechen den Parametern des AddCmd()-Aufrufs, sind
- aber in anderer Form. Als Beispiel:
+ <thing/commands.h>
- 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>, ...
+BESCHREIBUNG
+============
-BEMERKUNGEN:
- Cache-Closures sind bei Export immer genullt
+ Diese Property enthaelt ein Mapping mit den Befehlen, die dem Objekt
+ zugeordnet sind.
-SIEHE AUCH:
- /std/thing/commands.c, AddCmd(), RemoveCmd()
+ Sie sollte nicht von Hand manipuliert werden, sondern nur ueber die
+ Funktionen AddCmd() und RemoveCmd().
-16. Dez 2016 Gloinson
\ No newline at end of file
+ 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/props/P_COMPILER_PATH b/doc/props/P_COMPILER_PATH
index ecd2743..e67d01f 100644
--- a/doc/props/P_COMPILER_PATH
+++ b/doc/props/P_COMPILER_PATH
@@ -1,21 +1,40 @@
-NAME:
- P_COMPILER_PATH "compiler_path"
-DEFINIERT IN:
- /sys/v_compiler.h
+P_COMPILER_PATH
+***************
-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.
+NAME
+====
-BEISPIEL:
- SetProp(P_COMPILER_PATH,"/d/region/magier/vc/");
+ P_COMPILER_PATH "compiler_path"
-SIEHE AUCH:
- P_STD_OBJECT, virtual_compiler
--------------------------------------------------------------------------
+
+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/props/P_CONSUME_MSG b/doc/props/P_CONSUME_MSG
index 8b8a05a..0300037 100644
--- a/doc/props/P_CONSUME_MSG
+++ b/doc/props/P_CONSUME_MSG
@@ -1,24 +1,45 @@
-NAME:
- P_CONSUME_MSG "std_food_consume_msg"
-DEFINIERT IN:
- <sys/food.h>
+P_CONSUME_MSG
+*************
-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
+NAME
+====
-------------------------------------------------------------------------------
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
\ No newline at end of file
+ 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/props/P_CONTAINER b/doc/props/P_CONTAINER
index ed15ca5..e779f75 100644
--- a/doc/props/P_CONTAINER
+++ b/doc/props/P_CONTAINER
@@ -1,8 +1,21 @@
-NAME:
- P_CONTAINER "container"
-DEFINIERT IN:
- /sys/properties.h
+P_CONTAINER
+***********
-BESCHREIBUNG:
- *** KEINE BESCHREIBUNG VORHANDEN ***
+
+NAME
+====
+
+ P_CONTAINER "container"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/props/P_CONTENTS b/doc/props/P_CONTENTS
index 1212da7..fc9f20e 100644
--- a/doc/props/P_CONTENTS
+++ b/doc/props/P_CONTENTS
@@ -1,8 +1,21 @@
-NAME:
- P_CONTENTS "contents"
-DEFINIERT IN:
- /sys/container.h
+P_CONTENTS
+**********
-BESCHREIBUNG:
- *** OBSOLET! ***
+
+NAME
+====
+
+ P_CONTENTS "contents"
+
+
+DEFINIERT IN
+============
+
+ /sys/container.h
+
+
+BESCHREIBUNG
+============
+
+ *** OBSOLET! ***
diff --git a/doc/props/P_CORPSE b/doc/props/P_CORPSE
index bcb0ab6..762f03c 100644
--- a/doc/props/P_CORPSE
+++ b/doc/props/P_CORPSE
@@ -1,25 +1,43 @@
-NAME:
- P_CORPSE "corpse"
-DEFINIERT IN:
- /sys/properties.h
+P_CORPSE
+********
-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.
+NAME
+====
-SIEHE AUCH:
- P_NOCORPSE, P_ZAP_MSG, P_DIE_MSG, P_MURDER_MSG, P_KILL_MSG
+ 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/props/P_CURRENTDIR b/doc/props/P_CURRENTDIR
index 87bbd5c..b1dc2a4 100644
--- a/doc/props/P_CURRENTDIR
+++ b/doc/props/P_CURRENTDIR
@@ -1,15 +1,28 @@
-NAME:
- P_CURRENTDIR "currentdir"
-DEFINIERT IN:
- /sys/shells.h
+P_CURRENTDIR
+************
-BESCHREIBUNG:
- Momentanes Verzeichnis in dem der Magier ist.
- (nur fuer Magier von Belang)
+
+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
+ P_CURRENTDIR
Letzte Aenderung:
- 03.06.2015, Bugfix
+ 03.06.2015, Bugfix
diff --git a/doc/props/P_CURSED b/doc/props/P_CURSED
index 9253890..c3a9061 100644
--- a/doc/props/P_CURSED
+++ b/doc/props/P_CURSED
@@ -1,39 +1,56 @@
+
P_CURSED
+********
-NAME:
- P_CURSED "cursed"
-DEFINIERT IN:
- <properties.h>
+NAME
+====
-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...
+ P_CURSED "cursed"
- 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.
+DEFINIERT IN
+============
-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.
+ <properties.h>
- 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.
+BESCHREIBUNG
+============
-SIEHE AUCH:
- Eigenschaften: P_LEVEL
- Aehnlich: AddClass (CL_CURSE)
- Code: /std/armour, /std/weapon, /gilden/files.klerus/prayermaster
+ 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/props/P_DAMAGED b/doc/props/P_DAMAGED
index 671e0e0..91d5324 100644
--- a/doc/props/P_DAMAGED
+++ b/doc/props/P_DAMAGED
@@ -1,28 +1,41 @@
+
P_DAMAGED
+*********
-NAME:
- P_DAMAGED "item_damaged"
-DEFINIERT IN:
- <combat.h>
+NAME
+====
-BESCHREIBUNG:
- Ruestungen und Waffen koennen im Eifer des Gefechts beschaedigt werden.
- Der Grad der Beschaedigung sollte in dieser Property festgehalten
- werden.
+ P_DAMAGED "item_damaged"
- 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.
+DEFINIERT IN
+============
- P_DAMAGED bitte niemals direkt setzen, sondern immer ueber
- die Funktion Damage() manipulieren!
+ <combat.h>
-SIEHE AUCH:
- /std/armour.c, /std/weapon.c, TakeFlaw(), QueryFlaw(), Damage()
-----------------------------------------------------------------------------
+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/props/P_DAMAGE_MSG b/doc/props/P_DAMAGE_MSG
index 5906a3b..e9c71a8 100644
--- a/doc/props/P_DAMAGE_MSG
+++ b/doc/props/P_DAMAGE_MSG
@@ -1,44 +1,58 @@
+
P_DAMAGE_MSG
+************
-NAME:
- P_DAMAGE_MSG "std_p_dam_msg"
-DEFINIERT IN:
- /sys/living/combat.h
+NAME
+====
-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.
+ P_DAMAGE_MSG "std_p_dam_msg"
- 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.
+DEFINIERT IN
+============
- Ist ein Treffer x LP hart, werden die Meldungen des lphit-
- Arrays ausgegeben, dessen Wert am naechsten unter dem Schaden
- liegt.
+ /sys/living/combat.h
- 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
+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/props/P_DAM_DESC b/doc/props/P_DAM_DESC
index 59938c7..151f555 100644
--- a/doc/props/P_DAM_DESC
+++ b/doc/props/P_DAM_DESC
@@ -1,35 +1,56 @@
+
P_DAM_DESC
+**********
-NAME:
- P_DAM_DESC "dam_desc"
-DEFINIERT IN:
- <weapon/description.h>
+NAME
+====
-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.
+ P_DAM_DESC "dam_desc"
-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"}) );
+DEFINIERT IN
+============
-SIEHE AUCH:
- /std/weapon/description.c
+ <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/props/P_DAM_TYPE b/doc/props/P_DAM_TYPE
index 56fb4bb..e5088d2 100644
--- a/doc/props/P_DAM_TYPE
+++ b/doc/props/P_DAM_TYPE
@@ -1,22 +1,35 @@
+
P_DAM_TYPE
+**********
-NAME:
- P_DAM_TYPE "dam_type"
-DEFINIERT IN:
- <weapon.h>
+NAME
+====
-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.
+ P_DAM_TYPE "dam_type"
- Fragt man diese Property ab, bekommt man uebrigens immer ein Array von
- Strings zurueck.
-SIEHE AUCH:
- /std/weapon.c
+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/props/P_DEADS b/doc/props/P_DEADS
index ca44cd7..03f0c07 100644
--- a/doc/props/P_DEADS
+++ b/doc/props/P_DEADS
@@ -1,9 +1,22 @@
-NAME:
- P_DEADS "deads"
-DEFINIERT IN:
- /sys/living/life.h
+P_DEADS
+*******
-BESCHREIBUNG:
- Anzahl der Tode des Spielers seit Einfuehrung dieser Property (irgendwann
- im Dezember 94)
+
+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/props/P_DEAF b/doc/props/P_DEAF
index 8745dfd..570ac06 100644
--- a/doc/props/P_DEAF
+++ b/doc/props/P_DEAF
@@ -1,10 +1,23 @@
-NAME:
- P_DEAF "deaf"
-DEFINIERT IN:
- /sys/player/comm.h
+P_DEAF
+******
-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"
+
+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/props/P_DEATH_MSG b/doc/props/P_DEATH_MSG
index 4e044bf..d5de007 100644
--- a/doc/props/P_DEATH_MSG
+++ b/doc/props/P_DEATH_MSG
@@ -1,48 +1,79 @@
-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
+
+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/props/P_DEATH_SPONSORED_BY b/doc/props/P_DEATH_SPONSORED_BY
index 4f86a36..cae8532 100644
--- a/doc/props/P_DEATH_SPONSORED_BY
+++ b/doc/props/P_DEATH_SPONSORED_BY
@@ -1,25 +1,42 @@
-NAME:
- P_DEATH_SPONSORED_BY "responsible_wizard_for_death"
-DEFINIERT IN:
- /sys/living/combat.h
+P_DEATH_SPONSORED_BY
+********************
-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.
+NAME
+====
-BEISPIEL:
- SetProp(P_DEATH_SPONSORED_BY,"tilly");
-
+ P_DEATH_SPONSORED_BY "responsible_wizard_for_death"
-Last modified: Don Feb 15 14:01:00 2001 von Tilly
+
+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/props/P_DEFAULT_GUILD b/doc/props/P_DEFAULT_GUILD
index 28ca4e6..55abd50 100644
--- a/doc/props/P_DEFAULT_GUILD
+++ b/doc/props/P_DEFAULT_GUILD
@@ -1,25 +1,43 @@
-NAME:
- P_DEFAULT_GUILD "default_guild"
-DEFINIERT IN:
- /sys/new_skills.h
+P_DEFAULT_GUILD
+***************
-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).
+NAME
+====
-SIEHE AUCH:
- P_GUILD, P_VISIBLE_GUILD
+ 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/props/P_DEFAULT_NOTIFY_FAIL b/doc/props/P_DEFAULT_NOTIFY_FAIL
index 611e8df..351c96c 100644
--- a/doc/props/P_DEFAULT_NOTIFY_FAIL
+++ b/doc/props/P_DEFAULT_NOTIFY_FAIL
@@ -1,8 +1,21 @@
-NAME:
- P_DEFAULT_NOTIFY_FAIL "default_notify_fail"
-DEFINIERT IN:
- /sys/player.h
+P_DEFAULT_NOTIFY_FAIL
+*********************
-BESCHREIBUNG:
- Welche Fehlermeldung kommt, wenn kein Objekt ein notify_fail macht?
+
+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/props/P_DEFENDERS b/doc/props/P_DEFENDERS
index b471d45..a54134a 100644
--- a/doc/props/P_DEFENDERS
+++ b/doc/props/P_DEFENDERS
@@ -1,30 +1,45 @@
-NAME:
- P_DEFENDERS "defenders"
-DEFINIERT IN:
- /sys/new_skills.h
+P_DEFENDERS
+***********
-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
+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/props/P_DEFEND_FUNC b/doc/props/P_DEFEND_FUNC
index 02f1e8c..a9939e1 100644
--- a/doc/props/P_DEFEND_FUNC
+++ b/doc/props/P_DEFEND_FUNC
@@ -1,31 +1,50 @@
+
P_DEFEND_FUNC
+*************
-NAME:
- P_DEFEND_FUNC "defend_func"
-DEFINIERT IN:
- <armour.h>
+NAME
+====
-BESCHREIBUNG:
- Falls ein Objekt eine DefendFunc() fuer die Ruestung definiert, so muss
- dieses Objekt in dieser Property eingetragen sein.
+ P_DEFEND_FUNC "defend_func"
- 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!
+DEFINIERT IN
+============
-BEISPIELE:
- Siehe das Beispiel zu DefendFunc()
+ <armour.h>
-SIEHE AUCH:
- /std/armour.c, DefendFunc(), balance, grenzwerte
-----------------------------------------------------------------------------
+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/props/P_DEFUEL_AMOUNT_DRINK b/doc/props/P_DEFUEL_AMOUNT_DRINK
index 558e261..79dcfa5 100644
--- a/doc/props/P_DEFUEL_AMOUNT_DRINK
+++ b/doc/props/P_DEFUEL_AMOUNT_DRINK
@@ -1,20 +1,36 @@
-NAME:
- P_DEFUEL_AMOUNT_DRINK "defuel_amount_drink"
-DEFINIERT IN:
- /sys/defuel.h
+P_DEFUEL_AMOUNT_DRINK
+*********************
-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
+
+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/props/P_DEFUEL_AMOUNT_FOOD b/doc/props/P_DEFUEL_AMOUNT_FOOD
index a8554be..f61a23e 100644
--- a/doc/props/P_DEFUEL_AMOUNT_FOOD
+++ b/doc/props/P_DEFUEL_AMOUNT_FOOD
@@ -1,20 +1,36 @@
-NAME:
- P_DEFUEL_AMOUNT_FOOD "defuel_amount_food"
-DEFINIERT IN:
- /sys/defuel.h
+P_DEFUEL_AMOUNT_FOOD
+********************
-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
+
+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/props/P_DEFUEL_LIMIT_DRINK b/doc/props/P_DEFUEL_LIMIT_DRINK
index 0a59df4..d3a2c3c 100644
--- a/doc/props/P_DEFUEL_LIMIT_DRINK
+++ b/doc/props/P_DEFUEL_LIMIT_DRINK
@@ -1,21 +1,37 @@
-NAME:
- P_DEFUEL_LIMIT_DRINK "defuel_limit_drink"
-DEFINIERT IN:
- /sys/defuel.h
+P_DEFUEL_LIMIT_DRINK
+********************
-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
+
+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/props/P_DEFUEL_LIMIT_FOOD b/doc/props/P_DEFUEL_LIMIT_FOOD
index 26e33fd..bb012a3 100644
--- a/doc/props/P_DEFUEL_LIMIT_FOOD
+++ b/doc/props/P_DEFUEL_LIMIT_FOOD
@@ -1,21 +1,37 @@
-NAME:
- P_DEFUEL_LIMIT_FOOD "defuel_limit_food"
-DEFINIERT IN:
- /sys/defuel.h
+P_DEFUEL_LIMIT_FOOD
+*******************
-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
+
+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/props/P_DEFUEL_TIME_DRINK b/doc/props/P_DEFUEL_TIME_DRINK
index de5eaf0..3ff3b74 100644
--- a/doc/props/P_DEFUEL_TIME_DRINK
+++ b/doc/props/P_DEFUEL_TIME_DRINK
@@ -1,21 +1,37 @@
-NAME:
- P_DEFUEL_TIME_DRINK "defuel_time_drink"
-DEFINIERT IN:
- /sys/defuel.h
+P_DEFUEL_TIME_DRINK
+*******************
-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
+
+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/props/P_DEFUEL_TIME_FOOD b/doc/props/P_DEFUEL_TIME_FOOD
index d7bdd79..fcd80d0 100644
--- a/doc/props/P_DEFUEL_TIME_FOOD
+++ b/doc/props/P_DEFUEL_TIME_FOOD
@@ -1,21 +1,37 @@
-NAME:
- P_DEFUEL_TIME_FOOD "defuel_time_food"
-DEFINIERT IN:
- /sys/defuel.h
+P_DEFUEL_TIME_FOOD
+******************
-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
+
+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/props/P_DEPARTMSG b/doc/props/P_DEPARTMSG
index 515c8bd..917e01c 100644
--- a/doc/props/P_DEPARTMSG
+++ b/doc/props/P_DEPARTMSG
@@ -1,8 +1,21 @@
-NAME:
- P_DEPARTMSG "departmsg"
-DEFINIERT IN:
- /sys/transport.h
+P_DEPARTMSG
+***********
-BESCHREIBUNG:
- Meldung, mit der ein Transporter ablegt.
+
+NAME
+====
+
+ P_DEPARTMSG "departmsg"
+
+
+DEFINIERT IN
+============
+
+ /sys/transport.h
+
+
+BESCHREIBUNG
+============
+
+ Meldung, mit der ein Transporter ablegt.
diff --git a/doc/props/P_DESCRIPTION b/doc/props/P_DESCRIPTION
index d275cc7..4d32999 100644
--- a/doc/props/P_DESCRIPTION
+++ b/doc/props/P_DESCRIPTION
@@ -1,8 +1,21 @@
-NAME:
- P_DESCRIPTION "description"
-DEFINIERT IN:
- /sys/properties.h
+P_DESCRIPTION
+*************
-BESCHREIBUNG:
- Beschreibung des Spielers
+
+NAME
+====
+
+ P_DESCRIPTION "description"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ Beschreibung des Spielers
diff --git a/doc/props/P_DESTROY_BAD b/doc/props/P_DESTROY_BAD
index d563af9..94f00e5 100644
--- a/doc/props/P_DESTROY_BAD
+++ b/doc/props/P_DESTROY_BAD
@@ -1,29 +1,52 @@
-NAME:
- P_DESTROY_BAD "std_food_destroy_bad"
-DEFINIERT IN:
- <sys/food.h>
+P_DESTROY_BAD
+*************
-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
+NAME
+====
-------------------------------------------------------------------------------
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
\ No newline at end of file
+ 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/props/P_DESTRUCT_MSG b/doc/props/P_DESTRUCT_MSG
index 4b7e7e9..334c374 100644
--- a/doc/props/P_DESTRUCT_MSG
+++ b/doc/props/P_DESTRUCT_MSG
@@ -1,8 +1,21 @@
-NAME:
- P_DESTRUCT_MSG "destruct_msg"
-DEFINIERT IN:
- /sys/player/base.h
+P_DESTRUCT_MSG
+**************
-BESCHREIBUNG:
- Meldung, die beim Destructen Obj ausgegegen wird (nur Magier)
+
+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/props/P_DETAILS b/doc/props/P_DETAILS
index e23513a..e14c15c 100644
--- a/doc/props/P_DETAILS
+++ b/doc/props/P_DETAILS
@@ -1,25 +1,44 @@
-NAME:
- P_DETAILS "details"
-DEFINIERT IN:
- /sys/thing/description.h
+P_DETAILS
+*********
-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.
+NAME
+====
-SIEHE AUCH:
- Setzen: AddDetail()
- Loeschen: RemoveDetail()
- Aehnlich: P_SPECIAL_DETAILS
- Veraltet: AddSpecialDetail(), RemoveSpecialDetail()
- Sonstiges: GetDetail(), break_string()
+ 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/props/P_DIE_MSG b/doc/props/P_DIE_MSG
index 99f1d7c..0bd5d17 100644
--- a/doc/props/P_DIE_MSG
+++ b/doc/props/P_DIE_MSG
@@ -1,40 +1,56 @@
+
P_DIE_MSG
+*********
-NAME:
- P_DIE_MSG "die_msg"
-DEFINIERT IN:
- /sys/properties.h
+NAME
+====
-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".
+ P_DIE_MSG "die_msg"
- 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);
+DEFINIERT IN
+============
- Damit dann auch wirklich keine Leiche zurueckbleibt, wird zusaetzlich
- die Property P_NOCORPSE gesetzt.
+ /sys/properties.h
-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
-----------------------------------------------------------------------------
+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/props/P_DISABLE_ATTACK b/doc/props/P_DISABLE_ATTACK
index 25e051d..37544ae 100644
--- a/doc/props/P_DISABLE_ATTACK
+++ b/doc/props/P_DISABLE_ATTACK
@@ -1,46 +1,64 @@
-NAME:
- P_DISABLE_ATTACK "disable_attack"
-DEFINIERT IN:
- /sys/properties.h
+P_DISABLE_ATTACK
+****************
-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.
+NAME
+====
- 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.
+ P_DISABLE_ATTACK "disable_attack"
- Einen Gegner,der nie paralysiert werden koennen soll, kann man einfach
- per
- Set(P_DISABLE_ATTACK, function int () {return 0;}, F_SET_METHOD);
+DEFINIERT IN
+============
- erstellen, da bei diesem der Wert von P_DISABLE_ATTACK nicht mehr mit
- einem normalen SetProp()-Aufruf geaendert werden kann.
+ /sys/properties.h
-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
+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/props/P_DISABLE_COMMANDS b/doc/props/P_DISABLE_COMMANDS
index f0318e0..e66910a 100644
--- a/doc/props/P_DISABLE_COMMANDS
+++ b/doc/props/P_DISABLE_COMMANDS
@@ -1,74 +1,100 @@
+
P_DISABLE_COMMANDS
+******************
-NAME:
- P_DISABLE_COMMANDS "p_lib_disablecommands"
-DEFINIERT IN:
- /sys/player/command.h
+NAME
+====
-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.
+ P_DISABLE_COMMANDS "p_lib_disablecommands"
- 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.
+DEFINIERT IN
+============
-BEISPIEL:
+ /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()
+
+SIEHE AUCH
+==========
+
+ command(), query_command(), command_stack(), modify_command(),
+ this_player()
01.12.2012, Zesstra
diff --git a/doc/props/P_DISTRIBUTION b/doc/props/P_DISTRIBUTION
index 529c53e..51140ae 100644
--- a/doc/props/P_DISTRIBUTION
+++ b/doc/props/P_DISTRIBUTION
@@ -1,16 +1,31 @@
-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
\ No newline at end of file
+
+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/props/P_DMSG b/doc/props/P_DMSG
index f43fbb4..40af065 100644
--- a/doc/props/P_DMSG
+++ b/doc/props/P_DMSG
@@ -1,8 +1,21 @@
-NAME:
- P_DMSG "destmsg"
-DEFINIERT IN:
- /sys/player/base.h
+P_DMSG
+******
-BESCHREIBUNG:
- *** OBSOLET! *** Siehe P_DESTRUCT_MSG
+
+NAME
+====
+
+ P_DMSG "destmsg"
+
+
+DEFINIERT IN
+============
+
+ /sys/player/base.h
+
+
+BESCHREIBUNG
+============
+
+ *** OBSOLET! *** Siehe P_DESTRUCT_MSG
diff --git a/doc/props/P_DOMAIN b/doc/props/P_DOMAIN
index 80fd1f7..aad5288 100644
--- a/doc/props/P_DOMAIN
+++ b/doc/props/P_DOMAIN
@@ -1,31 +1,50 @@
-NAME:
- P_DOMAIN "lib_p_domain"
-DEFINIERT IN:
- /sys/room/description.h
+P_DOMAIN
+********
-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!
+NAME
+====
-BEISPIEL:
- In /d/inseln/zesstra/vulkanweg/room/r1 liefert
- QueryProp(P_DOMAIN)
- ein "Inseln" zurueck.
+ P_DOMAIN "lib_p_domain"
- In einem Raum der Chaosgilde:
- SetProp(P_DOMAIN, "Polar");
- damit der Raum als Raum der Region Polar angezeigt wird.
-SIEHE AUCH:
- gmcp
+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/props/P_DOOR_INFOS b/doc/props/P_DOOR_INFOS
index 8b5f71b..dc393da 100644
--- a/doc/props/P_DOOR_INFOS
+++ b/doc/props/P_DOOR_INFOS
@@ -1,44 +1,58 @@
-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
+P_DOOR_INFOS
+************
-SIEHE AUCH:
- NewDoor(), QueryDoorKey(), QueryDoorStatus(), SetDoorStatus(),
- /std/room/doors.c, /obj/doormaster.c, GetPhiolenInfos(), QueryAllDoors()
+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/props/P_DO_DESTRUCT b/doc/props/P_DO_DESTRUCT
index 7e9a230..6aa9384 100644
--- a/doc/props/P_DO_DESTRUCT
+++ b/doc/props/P_DO_DESTRUCT
@@ -1,17 +1,36 @@
-NAME:
- P_DO_DESTRUCT "do_destruct"
-DEFINIERT IN:
- /sys/properties.h
+P_DO_DESTRUCT
+*************
-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)
+NAME
+====
-LETZTE AENDERUNG:
- 22. Dez. 2015, Arathorn
+ 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/props/P_DRINK b/doc/props/P_DRINK
index f2fe982..028e987 100644
--- a/doc/props/P_DRINK
+++ b/doc/props/P_DRINK
@@ -1,25 +1,39 @@
-NAME:
- P_DRINK "drink"
-DEFINIERT IN:
- /sys/living/life.h
+P_DRINK
+*******
-BESCHREIBUNG:
- - Lebewesen
- Numerischer Wert fuer den Saettigungsgrad eines Lebewesens mit
- Getraenken. Der maximale Wert steht in P_MAX_DRINK.
+NAME
+====
- - 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
+ P_DRINK "drink"
-------------------------------------------------------------------------------
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
\ No newline at end of file
+
+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/props/P_DRINK_DELAY b/doc/props/P_DRINK_DELAY
index 0118843..1617b47 100644
--- a/doc/props/P_DRINK_DELAY
+++ b/doc/props/P_DRINK_DELAY
@@ -1,10 +1,23 @@
-NAME:
- P_DRINK_DELAY "drink_delay"
-DEFINIERT IN:
- /sys/living/life.h
+P_DRINK_DELAY
+*************
-BESCHREIBUNG:
- Anzahl der heart_beats, bis P_DRINK um einen Punkt sinkt.
- Aenderungen dieser Property in Spielern beduerfen der
- Genehmigung des EM fuer Balance.
+
+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/props/P_DRINK_FULL_MSG b/doc/props/P_DRINK_FULL_MSG
index 2903af3..1e5c2ce 100644
--- a/doc/props/P_DRINK_FULL_MSG
+++ b/doc/props/P_DRINK_FULL_MSG
@@ -1,24 +1,45 @@
-NAME:
- P_DRINK_FULL_MSG "std_food_drink_full_msg"
-DEFINIERT IN:
- <sys/food.h>
+P_DRINK_FULL_MSG
+****************
-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
+NAME
+====
-------------------------------------------------------------------------------
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
\ No newline at end of file
+ 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/props/P_DROP_MSG b/doc/props/P_DROP_MSG
index 5a4c9d7..9ccb875 100644
--- a/doc/props/P_DROP_MSG
+++ b/doc/props/P_DROP_MSG
@@ -1,62 +1,96 @@
+
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.
+NAME
+====
- 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"}));
- ...
- }
+ P_DROP_MSG "drop_message"
- 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
+
+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/props/P_EARMUFFS b/doc/props/P_EARMUFFS
index 97e6b1c..e5b4bbb 100644
--- a/doc/props/P_EARMUFFS
+++ b/doc/props/P_EARMUFFS
@@ -1,9 +1,22 @@
-NAME:
- P_EARMUFFS "earmuffs"
-DEFINIERT IN:
- /sys/properties.h
+P_EARMUFFS
+**********
-BESCHREIBUNG:
- Shouts von Spielern und Magiern mit Magierlevel < earmuffs werden
- abgeblockt (Nur fuer Magier).
+
+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/props/P_EATER_MSG b/doc/props/P_EATER_MSG
index 99ae4d3..132469d 100644
--- a/doc/props/P_EATER_MSG
+++ b/doc/props/P_EATER_MSG
@@ -1,23 +1,44 @@
-NAME:
- P_EATER_MSG "std_food_eater_msg"
-DEFINIERT IN:
- <sys/food.h>
+P_EATER_MSG
+***********
-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
+NAME
+====
-------------------------------------------------------------------------------
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
\ No newline at end of file
+ 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/props/P_EFFECTIVE_AC b/doc/props/P_EFFECTIVE_AC
index ff7dd53..5473d5d 100644
--- a/doc/props/P_EFFECTIVE_AC
+++ b/doc/props/P_EFFECTIVE_AC
@@ -1,87 +1,107 @@
+
P_EFFECTIVE_AC
+**************
-NAME:
- P_EFFECTIVE_AC "effective_ac"
-DEFINIERT IN:
- <combat.h>
+NAME
+====
-BESCHREIBUNG:
- Diese Property kommt sowohl in Ruestungen als auch in Waffen, die
- schuetzen sollen, zum Einsatz.
+ P_EFFECTIVE_AC "effective_ac"
- 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)
+DEFINIERT IN
+============
-BERMERKUNGEN:
- Das Kaempferspellbook verwendet fuer Paraden etc. P_EFFECTIVE_AC anstatt
- P_AC, wenn verfuegbar.
+ <combat.h>
-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());
+BESCHREIBUNG
+============
- int DefendFunc(...) {
- return random(20); // Mittelwert: 10
- }
- -> SetProp(P_EFFECTIVE_AC, 55); // 35 + 2*10 = 55
+ Diese Property kommt sowohl in Ruestungen als auch in Waffen, die
+ schuetzen sollen, zum Einsatz.
- // #2 Eine Ruestung mit P_AC von 35 und teilrandomisierter DefendFunc
- SetProp(P_AC, 35);
- SetProp(P_DEFEND_FUNC, this_object());
+ 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).
- int DefendFunc(...) {
- return 20 + random(10); // Mittelwert: 20 + 5
- }
- -> SetProp(P_EFFECTIVE_AC, 85); // 35 + 2*(20+5) = 85
+ 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)
- * 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);
+BERMERKUNGEN
+============
- // #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);
+ Das Kaempferspellbook verwendet fuer Paraden etc. P_EFFECTIVE_AC anstatt
+ P_AC, wenn verfuegbar.
- * 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);
+BEISPIELE
+=========
-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
+ * 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/props/P_EFFECTIVE_WC b/doc/props/P_EFFECTIVE_WC
index 0328629..aa16980 100644
--- a/doc/props/P_EFFECTIVE_WC
+++ b/doc/props/P_EFFECTIVE_WC
@@ -1,86 +1,112 @@
+
P_EFFECTIVE_WC
+**************
-NAME:
- P_EFFECTIVE_WC "effective_wc"
-DEFINIERT IN:
- <combat.h>
+NAME
+====
-BESCHREIBUNG:
- Diese Property kommt sowohl in Waffen als auch Ruestungen, die Schaden
- machen sollen, zum Einsatz.
+ P_EFFECTIVE_WC "effective_wc"
- 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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Das Kaempferspellbook verwendet bei Ruestungen P_AC, wenn
- P_EFFECTIVE_WC nicht gesetzt ist.
+ <combat.h>
-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
+BESCHREIBUNG
+============
- * 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.
+ Diese Property kommt sowohl in Waffen als auch Ruestungen, die Schaden
+ machen sollen, zum Einsatz.
- // #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]);
+ 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.
- // #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);
+ 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.
- // #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
+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/props/P_EMPTY_MSG b/doc/props/P_EMPTY_MSG
index 7248d8e..e91d622 100644
--- a/doc/props/P_EMPTY_MSG
+++ b/doc/props/P_EMPTY_MSG
@@ -1,24 +1,45 @@
-NAME:
- P_EMPTY_MSG "std_food_eater_msg"
-DEFINIERT IN:
- <sys/food.h>
+P_EMPTY_MSG
+***********
-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
+NAME
+====
-------------------------------------------------------------------------------
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
\ No newline at end of file
+ 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/props/P_EMPTY_PROPS b/doc/props/P_EMPTY_PROPS
index a8156d7..6f5c126 100644
--- a/doc/props/P_EMPTY_PROPS
+++ b/doc/props/P_EMPTY_PROPS
@@ -1,33 +1,54 @@
-NAME:
- P_EMPTY_PROPS "std_food_empty_props"
-DEFINIERT IN:
- <sys/food.h>
+P_EMPTY_PROPS
+*************
-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
+NAME
+====
-------------------------------------------------------------------------------
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
\ No newline at end of file
+ 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/props/P_ENABLE_IN_ATTACK_OUT b/doc/props/P_ENABLE_IN_ATTACK_OUT
index d60a807..0a64c74 100644
--- a/doc/props/P_ENABLE_IN_ATTACK_OUT
+++ b/doc/props/P_ENABLE_IN_ATTACK_OUT
@@ -1,33 +1,51 @@
-NAME:
- P_ENABLE_IN_ATTACK_OUT "enable_in_attack_out"
-DEFINIERT IN:
- /sys/combat.h
+P_ENABLE_IN_ATTACK_OUT
+**********************
-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.
+NAME
+====
-SIEHE AUCH:
- do_damage(), P_LAST_MOVE, /std/living/life.c
+ 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/props/P_ENEMY_DAMAGE b/doc/props/P_ENEMY_DAMAGE
index 216339d..bad9c99 100644
--- a/doc/props/P_ENEMY_DAMAGE
+++ b/doc/props/P_ENEMY_DAMAGE
@@ -1,31 +1,48 @@
+
P_ENEMY_DAMAGE
+**************
-NAME:
- P_ENEMY_DAMAGE "enemy_damage"
-DEFINIERT IN:
- <living/life.h>
+NAME
+====
-BESCHREIBUNG:
- In dieser Property ist vermerkt, welches Wesen diesem Wesen wieviel
- Schaden zugefuegt hat.
+ P_ENEMY_DAMAGE "enemy_damage"
- 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)
+DEFINIERT IN
+============
-BEMERKUNGEN:
- Diese Property laesst sich nur abfragen!
+ <living/life.h>
-SIEHE AUCH:
- P_HELPER_NPC
-----------------------------------------------------------------------------
+
+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/props/P_ENEMY_DEATH_SEQUENCE b/doc/props/P_ENEMY_DEATH_SEQUENCE
index 260d325..03b2bec 100644
--- a/doc/props/P_ENEMY_DEATH_SEQUENCE
+++ b/doc/props/P_ENEMY_DEATH_SEQUENCE
@@ -1,44 +1,61 @@
+
P_ENEMY_DEATH_SEQUENCE
+**********************
-NAME:
- P_ENEMY_DEATH_SEQUENCE "enemy_death_sequence"
-DEFINIERT IN:
- /sys/living/combat.h
+NAME
+====
-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.
+ P_ENEMY_DEATH_SEQUENCE "enemy_death_sequence"
- 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");
+DEFINIERT IN
+============
- // eigene DSQ im Todesraumformat:
- SetProp(P_ENEMY_DEATH_SEQUENCE,
- ({ 2, ([1: "DU LERNST AUS DEINEM FEHLER.\n"])}));
+ /sys/living/combat.h
- // 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
+BESCHREIBUNG
+============
-10. Nov 2011 Gloinson
\ No newline at end of file
+ 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/props/P_ENTERCMDS b/doc/props/P_ENTERCMDS
index 0f7e3d9..fc6f72f 100644
--- a/doc/props/P_ENTERCMDS
+++ b/doc/props/P_ENTERCMDS
@@ -1,33 +1,57 @@
-NAME:
- P_ENTERCMDS "leavecmds"
-DEFINIERT IN:
- /sys/transport.h
+P_ENTERCMDS
+***********
-BESCHREIBUNG:
- Ein Array mit Befehlen, die zum Betreten des Transporters fuehren.
-BEISPIEL:
- SetProp(P_ENTERCMDS,({ "betrete","betritt" }) );
+NAME
+====
- 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.
+ P_ENTERCMDS "leavecmds"
-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.
+DEFINIERT IN
+============
- Sollen Kommandos zum Betreten UND Verlassen eines Transporters ver-
- wendet werden koennen, muessen diese in P_TRAVEL_CMDS gesetzt werden.
+ /sys/transport.h
-SIEHE AUCH:
- P_LEAVEFAIL, P_ENTERFAIL, P_LEAVECMDS, P_TRAVEL_CMDS, transporter,
-LETZTE AENDERUNG:
- Don, 24.01.2002, 10:15:07h von Tilly
-
\ No newline at end of file
+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/props/P_ENTERFAIL b/doc/props/P_ENTERFAIL
index 2ecd1e6..5291065 100644
--- a/doc/props/P_ENTERFAIL
+++ b/doc/props/P_ENTERFAIL
@@ -1,24 +1,48 @@
-NAME:
- P_ENTERFAIL "enterfail"
-DEFINIERT IN:
- /sys/transport.h
+P_ENTERFAIL
+***********
-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" }) );
+NAME
+====
-SIEHE AUCH:
- P_ENTERMSG, P_LEAVEFAIL, P_LEAVEMSG, transporter
+ P_ENTERFAIL "enterfail"
-LETZTE AENDERUNG:
- Don, 24.01.2002, 10:15:07h von Tilly
+
+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/props/P_ENTERMSG b/doc/props/P_ENTERMSG
index 2a2128e..9ba314d 100644
--- a/doc/props/P_ENTERMSG
+++ b/doc/props/P_ENTERMSG
@@ -1,18 +1,40 @@
-NAME:
- P_ENTERMSG "entermsg"
-DEFINIERT IN:
- /sys/transport.h
+P_ENTERMSG
+**********
-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" }) );
+NAME
+====
-SIEHE AUCH:
- P_ENTERFAIL, P_LEAVEFAIL, P_LEAVEMSG, transporter
+ P_ENTERMSG "entermsg"
-LETZTER AENDERUNG:
- Don, 24.01.2002, 10:15:07h von Tilly
+
+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/props/P_ENV_MSG b/doc/props/P_ENV_MSG
index b39e2c1..e969399 100644
--- a/doc/props/P_ENV_MSG
+++ b/doc/props/P_ENV_MSG
@@ -1,26 +1,47 @@
-NAME:
- P_ENV_MSG "std_food_env_msg"
-DEFINIERT IN:
- <sys/food.h>
+P_ENV_MSG
+*********
-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
+NAME
+====
-------------------------------------------------------------------------------
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
\ No newline at end of file
+ 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/props/P_ENV_TOO_HEAVY_MSG b/doc/props/P_ENV_TOO_HEAVY_MSG
index 8c73ac1..23c1d6c 100644
--- a/doc/props/P_ENV_TOO_HEAVY_MSG
+++ b/doc/props/P_ENV_TOO_HEAVY_MSG
@@ -1,31 +1,50 @@
-NAME:
- P_ENV_TOO_HEAVY_MSG "env_too_heavy_msg"
-DEFINIERT IN:
- /sys/thing/moving.h
+P_ENV_TOO_HEAVY_MSG
+*******************
-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.");
+NAME
+====
-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
+ 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/props/P_EQUIP_TIME b/doc/props/P_EQUIP_TIME
index 71b2f35..ee0d07f 100644
--- a/doc/props/P_EQUIP_TIME
+++ b/doc/props/P_EQUIP_TIME
@@ -1,26 +1,39 @@
+
P_EQUIP_TIME
+************
-NAME:
- P_EQUIP_TIME "equip_time"
-DEFINIERT IN:
- /sys/combat.h
+NAME
+====
-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());
+ P_EQUIP_TIME "equip_time"
-SIEHE AUCH:
- Verwandt: P_LAST_USE
- Waffen: P_UNWIELD_TIME
- DoWield()
- Ruestungen: DoWear()
- Sonstiges: time()
- /std/weapon/combat.c, /std/armour/combat.c
-----------------------------------------------------------------------------
+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/props/P_EVAL_FACTORS b/doc/props/P_EVAL_FACTORS
index 04e881e..ed83d4e 100644
--- a/doc/props/P_EVAL_FACTORS
+++ b/doc/props/P_EVAL_FACTORS
@@ -1,8 +1,21 @@
-NAME:
- P_EVAL_FACTORS "inpc_eval_factors"
-DEFINIERT IN:
- /sys/inpc/eval.h
+P_EVAL_FACTORS
+**************
-BESCHREIBUNG:
- *** KEINE BESCHREIBUNG VORHANDEN ***
+
+NAME
+====
+
+ P_EVAL_FACTORS "inpc_eval_factors"
+
+
+DEFINIERT IN
+============
+
+ /sys/inpc/eval.h
+
+
+BESCHREIBUNG
+============
+
+ *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/props/P_EVAL_OFFSETS b/doc/props/P_EVAL_OFFSETS
index d82ef39..e571f51 100644
--- a/doc/props/P_EVAL_OFFSETS
+++ b/doc/props/P_EVAL_OFFSETS
@@ -1,8 +1,21 @@
-NAME:
- P_EVAL_OFFSETS "inpc_eval_offsets"
-DEFINIERT IN:
- /sys/inpc/eval.h
+P_EVAL_OFFSETS
+**************
-BESCHREIBUNG:
- *** KEINE BESCHREIBUNG VORHANDEN ***
+
+NAME
+====
+
+ P_EVAL_OFFSETS "inpc_eval_offsets"
+
+
+DEFINIERT IN
+============
+
+ /sys/inpc/eval.h
+
+
+BESCHREIBUNG
+============
+
+ *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/props/P_EXITS b/doc/props/P_EXITS
index 9a90c60..c31bac3 100644
--- a/doc/props/P_EXITS
+++ b/doc/props/P_EXITS
@@ -1,24 +1,45 @@
-NAME:
- P_EXITS "exits"
-DEFINIERT IN:
- /sys/properties.h
+P_EXITS
+*******
-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
+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/props/P_EXTRA_LOOK b/doc/props/P_EXTRA_LOOK
new file mode 100644
index 0000000..e4f050e
--- /dev/null
+++ b/doc/props/P_EXTRA_LOOK
@@ -0,0 +1,52 @@
+
+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/props/P_FAO b/doc/props/P_FAO
index 62f33e1..33f673e 100644
--- a/doc/props/P_FAO
+++ b/doc/props/P_FAO
@@ -1,19 +1,33 @@
+
P_FAO
+*****
-NAME:
- P_FAO "fraternitasdonoarchmagorum"
-DEFINIERT IN:
- <player/fao.h>
+NAME
+====
-BESCHREIBUNG:
- Fraternitas-relevante Property.
+ P_FAO "fraternitasdonoarchmagorum"
- Genaue Informationen unbekannt.
- Schreibender Zugriff ist nur EMs oder dem FAOMASTER (s. Headerfile)
- moeglich.
-SIEHE AUCH:
- P_FAO_PORTALS
+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/props/P_FAO_PORTALS b/doc/props/P_FAO_PORTALS
index 465750a..5d80c90 100644
--- a/doc/props/P_FAO_PORTALS
+++ b/doc/props/P_FAO_PORTALS
@@ -1,22 +1,36 @@
+
P_FAO_PORTALS
+*************
-NAME:
- P_FAO_PORTALS "fraternitasdonoarchmagorumPORTALS"
-DEFINIERT IN:
- <player/fao.h>
+NAME
+====
-BESCHREIBUNG:
- Fraternitas-relevante Property.
+ P_FAO_PORTALS "fraternitasdonoarchmagorumPORTALS"
- 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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- P_FAO_PORTALS, P_SEERDOORS
-
+ <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/props/P_FISH b/doc/props/P_FISH
index c694c09..0fa259f 100644
--- a/doc/props/P_FISH
+++ b/doc/props/P_FISH
@@ -1,75 +1,92 @@
-NAME:
- P_FISH "fish"
-DEFINIERT IN:
- /sys/fishing.h
+P_FISH
+******
-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:
+NAME
+====
- 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
+ P_FISH "fish"
- 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.
+DEFINIERT IN
+============
- 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.
-
+ /sys/fishing.h
- 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:
+BESCHREIBUNG
+============
- Properties: P_WATER
- Methoden: GetAquarium(L)
+ 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/props/P_FLAGS b/doc/props/P_FLAGS
index 3c54aea..3962aed 100644
--- a/doc/props/P_FLAGS
+++ b/doc/props/P_FLAGS
@@ -1,8 +1,21 @@
-NAME:
- P_FLAGS "can_flags"
-DEFINIERT IN:
- /sys/player/base.h
+P_FLAGS
+*******
-BESCHREIBUNG:
- Flags des Spielers
+
+NAME
+====
+
+ P_FLAGS "can_flags"
+
+
+DEFINIERT IN
+============
+
+ /sys/player/base.h
+
+
+BESCHREIBUNG
+============
+
+ Flags des Spielers
diff --git a/doc/props/P_FOLLOW_SILENT b/doc/props/P_FOLLOW_SILENT
index 7662ad1..6dd07b3 100644
--- a/doc/props/P_FOLLOW_SILENT
+++ b/doc/props/P_FOLLOW_SILENT
@@ -1,9 +1,22 @@
-NAME:
- P_FOLLOW_SILENT "follow_silent"
-DEFINIERT IN:
- /sys/player/base.h
+P_FOLLOW_SILENT
+***************
-BESCHREIBUNG:
- Wenn diese Property 1 ist, wird der MOVE vom verfolge Silent ausge-
- fuehrt.
+
+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/props/P_FOOD b/doc/props/P_FOOD
index 769694f..3858431 100644
--- a/doc/props/P_FOOD
+++ b/doc/props/P_FOOD
@@ -1,24 +1,38 @@
-NAME:
- P_FOOD "food"
-DEFINIERT IN:
- /sys/living/life.h
+P_FOOD
+******
-BESCHREIBUNG:
- - Lebewesen
- Numerischer Wert fuer den Saettigungsgrad eines Lebewesens.
- Der maximale Wert steht in P_MAX_FOOD.
+NAME
+====
- - 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.
+ P_FOOD "food"
-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
\ No newline at end of file
+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/props/P_FOOD_DELAY b/doc/props/P_FOOD_DELAY
index 11ccf6e..f4eb2df 100644
--- a/doc/props/P_FOOD_DELAY
+++ b/doc/props/P_FOOD_DELAY
@@ -1,10 +1,23 @@
-NAME:
- P_FOOD_DELAY "food_delay"
-DEFINIERT IN:
- /sys/living/life.h
+P_FOOD_DELAY
+************
-BESCHREIBUNG:
- Anzahl der heart_beats, bis P_FOOD um einen Punkt sinkt.
- Aenderungen dieser Property in Spielern beduerfen der
- Genehmigung des EM fuer Balance.
+
+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/props/P_FOOD_FULL_MSG b/doc/props/P_FOOD_FULL_MSG
index a331ec5..f5c1bce 100644
--- a/doc/props/P_FOOD_FULL_MSG
+++ b/doc/props/P_FOOD_FULL_MSG
@@ -1,24 +1,45 @@
-NAME:
- P_FOOD_FULL_MSG "std_food_full_msg"
-DEFINIERT IN:
- <sys/food.h>
+P_FOOD_FULL_MSG
+***************
-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
+NAME
+====
-------------------------------------------------------------------------------
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
\ No newline at end of file
+ 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/props/P_FORCE_MURDER_MSG b/doc/props/P_FORCE_MURDER_MSG
index cf0157c..709ef4e 100644
--- a/doc/props/P_FORCE_MURDER_MSG
+++ b/doc/props/P_FORCE_MURDER_MSG
@@ -1,39 +1,57 @@
-NAME:
- P_FORCE_MURDER_MSG "force_murder_msg"
-DEFINIERT IN:
- /sys/properties.h
+P_FORCE_MURDER_MSG
+******************
-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.
+NAME
+====
-SIEHE AUCH:
- P_MURDER_MSG, P_ZAP_MSG, P_KILL_MSG, P_DIE_MSG, P_CORPSE, P_NOCORPSE
+ 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/props/P_FREE_HANDS b/doc/props/P_FREE_HANDS
index 6143cad..c8311cc 100644
--- a/doc/props/P_FREE_HANDS
+++ b/doc/props/P_FREE_HANDS
@@ -1,22 +1,40 @@
+
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.
+NAME
+====
-BEMERKUNGEN:
- Keine echte Property. Die Methode /std/living/combat::_query_free_hands
- stellt die Daten zusammen. Nicht setzen!
+ P_FREE_HANDS "free_hands"
-SIEHE AUCH:
- P_HANDS, P_HANDS_USED_BY
- P_MAX_HANDS, P_USED_HANDS
- UseHands, FreeHands
- /std/weapon.c, /std/spellbook.c
+
+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/props/P_FRIEND b/doc/props/P_FRIEND
index ded080c..b22203b 100644
--- a/doc/props/P_FRIEND
+++ b/doc/props/P_FRIEND
@@ -1,24 +1,39 @@
-NAME:
- P_FRIEND "friend"
-DEFINIERT IN:
- <combat.h>
+P_FRIEND
+********
-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
+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/props/P_FROG b/doc/props/P_FROG
index 5f64eac..71badbe 100644
--- a/doc/props/P_FROG
+++ b/doc/props/P_FROG
@@ -1,8 +1,21 @@
-NAME:
- P_FROG "frog"
-DEFINIERT IN:
- /sys/living/life.h
+P_FROG
+******
-BESCHREIBUNG:
- Gesetzt, wenn der Spieler ein Frosch ist.
+
+NAME
+====
+
+ P_FROG "frog"
+
+
+DEFINIERT IN
+============
+
+ /sys/living/life.h
+
+
+BESCHREIBUNG
+============
+
+ Gesetzt, wenn der Spieler ein Frosch ist.
diff --git a/doc/props/P_FUEL b/doc/props/P_FUEL
index 890ca60..79f8515 100644
--- a/doc/props/P_FUEL
+++ b/doc/props/P_FUEL
@@ -1,26 +1,48 @@
-NAME:
- P_FUEL "fuel"
-DEFINIERT IN:
- /sys/properties.h
+P_FUEL
+******
-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.
+NAME
+====
-HINWEIS:
- Fuer Aenderungen an der Property kann auch die Funktion AddFuel()
- verwendet werden.
+ P_FUEL "fuel"
-SIEHE AUCH:
- Basisklassen: /std/lightsource.c
- Properties: P_LIGHTDESC, P_DO_DESTRUCT, P_LIGHT
- Methoden: AddFuel(L)
-LETZTE AENDERUNG:
- 22. Dez. 2015, Arathorn
+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/props/P_FUNC_MSG b/doc/props/P_FUNC_MSG
index b4f9d1e..adcca1a 100644
--- a/doc/props/P_FUNC_MSG
+++ b/doc/props/P_FUNC_MSG
@@ -1,21 +1,40 @@
-NAME:
- P_FUNC_MSG "func_msg"
-DEFINIERT IN:
- /sys/room/description.h
+P_FUNC_MSG
+**********
-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.
+NAME
+====
-ANMERKUNGEN:
- Bitte AddRoomMessage() zum Hinzufuegen/Ueberschreiben benutzen!
+ P_FUNC_MSG "func_msg"
-SIEHE AUCH:
- LFuns: AddRoomMessage()
- Verwandt: tell_room(), ReceiveMsg()
- Props: P_ROOM_MSG, P_MSG_PROB
+
+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/props/P_FW_ALWAYS_READABLE b/doc/props/P_FW_ALWAYS_READABLE
index 31700ed..f770431 100644
--- a/doc/props/P_FW_ALWAYS_READABLE
+++ b/doc/props/P_FW_ALWAYS_READABLE
@@ -1,8 +1,21 @@
-NAME:
- P_FW_ALWAYS_READABLE "fw_always_readable"
-DEFINIERT IN:
- /sys/properties.h
+P_FW_ALWAYS_READABLE
+********************
-BESCHREIBUNG:
- *** KEINE BESCHREIBUNG VORHANDEN ***
+
+NAME
+====
+
+ P_FW_ALWAYS_READABLE "fw_always_readable"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/props/P_FW_UNDERSTAND b/doc/props/P_FW_UNDERSTAND
index ff8f6e6..2884555 100644
--- a/doc/props/P_FW_UNDERSTAND
+++ b/doc/props/P_FW_UNDERSTAND
@@ -1,8 +1,21 @@
-NAME:
- P_FW_UNDERSTAND "fw_understand"
-DEFINIERT IN:
- /sys/properties.h
+P_FW_UNDERSTAND
+***************
-BESCHREIBUNG:
- *** KEINE BESCHREIBUNG VORHANDEN ***
+
+NAME
+====
+
+ P_FW_UNDERSTAND "fw_understand"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/props/P_GENDER b/doc/props/P_GENDER
index 93f73dc..c2a3f77 100644
--- a/doc/props/P_GENDER
+++ b/doc/props/P_GENDER
@@ -1,9 +1,22 @@
-NAME:
- P_GENDER "gender"
-DEFINIERT IN:
- /sys/thing/language.h
+P_GENDER
+********
-BESCHREIBUNG:
- Grammatikalisches Geschlecht des Objektes:
- (Definiert in language.h) MALE, FEMALE oder NEUTER
+
+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/props/P_GHOST b/doc/props/P_GHOST
index 9cbf309..31c9f2d 100644
--- a/doc/props/P_GHOST
+++ b/doc/props/P_GHOST
@@ -1,8 +1,21 @@
-NAME:
- P_GHOST "ghost"
-DEFINIERT IN:
- /sys/living/life.h
+P_GHOST
+*******
-BESCHREIBUNG:
- Gesetzt, wenn der Spieler tot ist.
+
+NAME
+====
+
+ P_GHOST "ghost"
+
+
+DEFINIERT IN
+============
+
+ /sys/living/life.h
+
+
+BESCHREIBUNG
+============
+
+ Gesetzt, wenn der Spieler tot ist.
diff --git a/doc/props/P_GIVE_MSG b/doc/props/P_GIVE_MSG
index bd6a624..e21dbad 100644
--- a/doc/props/P_GIVE_MSG
+++ b/doc/props/P_GIVE_MSG
@@ -1,65 +1,83 @@
+
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.
+NAME
+====
- Folgende Werte sind moeglich:
+ P_GIVE_MSG "give_message"
- o 0
- Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
- o NO_PNG_MSG == -1
- Es wird keinerlei Meldung ausgegeben
+DEFINIERT IN
+============
- 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.
+ /sys/living/put_and_get.h
- 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.
+BESCHREIBUNG
+============
-BEISPIEL:
- void create() {
- ...
- SetProp( P_SHORT, "Etwas Sand" );
- SetProp( P_LONG, break_string(
- "Ein wenig magischer Sand. Sehr feinkruemelig.",78 ));
+ Mit P_GIVE_MSG kann man die Meldung, die man beim Uebergeben eines
+ Objektes bekommt, modifizieren.
- SetProp( P_NAME, "Sand" );
- AddId( ({"sand"}) );
- SetProp( P_GENDER, MALE );
+ Folgende Werte sind moeglich:
- 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."}));
- ...
- }
+ o 0
+ Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
- Das ganze fuehrt bei Ugars "gib sand an peter" zu folgenden
- Meldungen:
+ o NO_PNG_MSG == -1
+ Es wird keinerlei Meldung ausgegeben
- 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."
+ 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.
-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
+ 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/props/P_GLOBAL_SKILLPROPS b/doc/props/P_GLOBAL_SKILLPROPS
index fc12c1e..1e3533b 100644
--- a/doc/props/P_GLOBAL_SKILLPROPS
+++ b/doc/props/P_GLOBAL_SKILLPROPS
@@ -1,27 +1,46 @@
-NAME:
- P_GLOBAL_SKILLPROPS "sm_global"
-DEFINIERT IN:
- /sys/new_skills.h
+P_GLOBAL_SKILLPROPS
+*******************
-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]));
+NAME
+====
-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
+ P_GLOBAL_SKILLPROPS "sm_global"
-3. Okt 2011 Gloinson
\ No newline at end of file
+
+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/props/P_GUARD b/doc/props/P_GUARD
index ebeb989..7128df6 100644
--- a/doc/props/P_GUARD
+++ b/doc/props/P_GUARD
@@ -1,50 +1,70 @@
+
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()
+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/props/P_GUILD b/doc/props/P_GUILD
index bcffb4c..c3c13cb 100644
--- a/doc/props/P_GUILD
+++ b/doc/props/P_GUILD
@@ -1,22 +1,40 @@
+
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.
+NAME
+====
-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.
+ P_GUILD "guild"
-SIEHE AUCH:
- P_DEFAULT_GUILD, P_VISIBLE_GUILD
- P_GUILD_TITLE, P_SUBGUILD_TITLE
+
+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/props/P_GUILD_DEACTIVATE_SKILLS b/doc/props/P_GUILD_DEACTIVATE_SKILLS
index 019da30..a53d6ce 100644
--- a/doc/props/P_GUILD_DEACTIVATE_SKILLS
+++ b/doc/props/P_GUILD_DEACTIVATE_SKILLS
@@ -1,38 +1,50 @@
-PROPERTY:
- P_GUILD_DEACTIVATE_SKILLS "guild_deactivate_skills"
+P_GUILD_DEACTIVATE_SKILLS
+*************************
-DEFINIERT IN:
- new_skills.h
+PROPERTY
+========
-BESCHREIBUNG:
+ P_GUILD_DEACTIVATE_SKILLS "guild_deactivate_skills"
- 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.
+DEFINIERT IN:
- 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.
+ new_skills.h
- Diese Property wird nur bei einem Neuerzeugen des Spielers neu
- ausgelesen, da es sonst zuviel Rechenzeit kostet.
-BEISPIEL:
+BESCHREIBUNG
+============
- Jede Gilde, die keine Waffenskills benutzen soll (oder selbst welche hat)
- enthaelt folgenden Befehl:
+ 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.
- 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:
+ 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.
-2003-01-30, 14:15, Humni
+ 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/props/P_GUILD_DEFAULT_SPELLBOOK b/doc/props/P_GUILD_DEFAULT_SPELLBOOK
index 9ad9150..4d6bbd0 100644
--- a/doc/props/P_GUILD_DEFAULT_SPELLBOOK
+++ b/doc/props/P_GUILD_DEFAULT_SPELLBOOK
@@ -1,23 +1,44 @@
-NAME:
- P_GUILD_DEFAULT_SPELLBOOK "guild_sb"
-DEFINIERT IN:
- /sys/new_skills.h
+P_GUILD_DEFAULT_SPELLBOOK
+*************************
-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.
+NAME
+====
-BEISPIELE:
- Bei Zauberern waere folgendes denkbar:
- SetProp(P_GUILD_DEFAULT_SPELLBOOK,"magie_sp");
- Das Spellbook ist hierbei unter "/spellbooks/magie_sp.c" zu finden.
+ P_GUILD_DEFAULT_SPELLBOOK "guild_sb"
-SIEHE AUCH:
- P_GUILD
-----------------------------------------------------------------------------
+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/props/P_GUILD_FEMALE_TITLES b/doc/props/P_GUILD_FEMALE_TITLES
index b1528e9..c06947d 100644
--- a/doc/props/P_GUILD_FEMALE_TITLES
+++ b/doc/props/P_GUILD_FEMALE_TITLES
@@ -1,24 +1,42 @@
-NAME:
- P_GUILD_FEMALE_TITLES "guild_female_titles"
-DEFINIERT IN:
- /sys/new_skills.h
+P_GUILD_FEMALE_TITLES
+*********************
-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 ;)"]));
+NAME
+====
-SIEHE AUCH:
- P_GENDER, P_GUILD_LEVEL, P_GUILD_TITLE, P_GUILD_MALE_TITLES
+ 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/props/P_GUILD_LEVEL b/doc/props/P_GUILD_LEVEL
index 4920449..f38701c 100644
--- a/doc/props/P_GUILD_LEVEL
+++ b/doc/props/P_GUILD_LEVEL
@@ -1,23 +1,41 @@
-NAME:
- P_GUILD_LEVEL "guild_level"
-DEFINIERT IN:
- /sys/new_skills.h
+P_GUILD_LEVEL
+*************
-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.
+NAME
+====
-SIEHE AUCH:
- P_GUILD, P_GUILD_TITLE, P_GUILD_MALE_TITLES, P_GUILD_FEMALE_TITLES
+ 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/props/P_GUILD_LEVELS b/doc/props/P_GUILD_LEVELS
index 80d2237..9b9b80d 100644
--- a/doc/props/P_GUILD_LEVELS
+++ b/doc/props/P_GUILD_LEVELS
@@ -1,35 +1,56 @@
-NAME:
- P_GUILD_LEVELS "guild_levels"
-DEFINIERT IN:
- /sys/new_skills.h
+P_GUILD_LEVELS
+**************
-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.
+NAME
+====
-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";
- }
+ P_GUILD_LEVELS "guild_levels"
-SIEHE AUCH:
- P_GUILD_LEVEL, P_GUILD_RESTRICTIONS, /std/restriction_checker.c
-----------------------------------------------------------------------------
+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/props/P_GUILD_MALE_TITLES b/doc/props/P_GUILD_MALE_TITLES
index 27e05a5..41cb773 100644
--- a/doc/props/P_GUILD_MALE_TITLES
+++ b/doc/props/P_GUILD_MALE_TITLES
@@ -1,24 +1,42 @@
-NAME:
- P_GUILD_MALE_TITLES "guild_male_titles"
-DEFINIERT IN:
- /sys/new_skills.h
+P_GUILD_MALE_TITLES
+*******************
-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"]));
+NAME
+====
-SIEHE AUCH:
- P_GENDER, P_GILD_LEVEL, P_GUILD_TITLE, P_GUILD_FEMALE_TITLES
+ 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/props/P_GUILD_PREPAREBLOCK b/doc/props/P_GUILD_PREPAREBLOCK
index e429a49..ee1c361 100644
--- a/doc/props/P_GUILD_PREPAREBLOCK
+++ b/doc/props/P_GUILD_PREPAREBLOCK
@@ -1,37 +1,60 @@
+
+P_GUILD_PREPAREBLOCK
+********************
+
+
P_GUILD_PREPAREBLOCK (int)
+==========================
-NAME:
- P_GUILD_PREPAREBLOCK "guild_prepareblock"
-DEFINIERT IN:
- /sys/new_skills.h
+NAME
+====
-BESCHREIBUNG:
- Diese Property enthaelt die Information, ob das Lebewesen in
- der Konzentrationsphase eines Spells weiterkaempft oder ob
- die Angriffe derweil ausgesetzt werden.
+ P_GUILD_PREPAREBLOCK "guild_prepareblock"
-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
+DEFINIERT IN
+============
- if ( IsGuildMember(pl) )
- pl->SetProp(P_GUILD_PREPAREBLOCK,1);
+ /sys/new_skills.h
- Resultat: Kein Ausfuehren von Attack(), wenn pl sich auf einen
- Zauberspruch konzentriert.
-SIEHE AUCH:
- P_PREPARED_SPELL
+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/props/P_GUILD_RATING b/doc/props/P_GUILD_RATING
index df5800a..af9c24e 100644
--- a/doc/props/P_GUILD_RATING
+++ b/doc/props/P_GUILD_RATING
@@ -1,22 +1,40 @@
-NAME:
- P_GUILD_RATING "guild_rating"
-DEFINIERT IN:
- /sys/new_skills.h
+P_GUILD_RATING
+**************
-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.
+NAME
+====
-SIEHE AUCH:
- P_NEWSKILLS, GuildRating
+ 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/props/P_GUILD_RESTRICTIONS b/doc/props/P_GUILD_RESTRICTIONS
index 8bbabc1..c94ccf3 100644
--- a/doc/props/P_GUILD_RESTRICTIONS
+++ b/doc/props/P_GUILD_RESTRICTIONS
@@ -1,37 +1,59 @@
-NAME:
- P_GUILD_RESTRICTIONS "guild_rest"
-DEFINIERT IN:
- /sys/new_skills.h
+P_GUILD_RESTRICTIONS
+********************
-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.
+NAME
+====
-BEISPIELE:
- Ein paar moegliche Abfragen waeren folgende:
- string check(object pl);
+ P_GUILD_RESTRICTIONS "guild_rest"
- 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";
- }
+DEFINIERT IN
+============
-SIEHE AUCH:
- Gildenfkt.:
- * Ein/Austritt: beitreten, bei_oder_aus_treten, austreten
- * Sonstiges: P_GUILD_LEVELS
- Sonstiges: /std/restriction_checker.c
+ /sys/new_skills.h
-3. Okt 2011 Gloinson
\ No newline at end of file
+
+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/props/P_GUILD_SKILLS b/doc/props/P_GUILD_SKILLS
index d7e30a2..232a5cf 100644
--- a/doc/props/P_GUILD_SKILLS
+++ b/doc/props/P_GUILD_SKILLS
@@ -1,24 +1,42 @@
+
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.
+NAME
+====
-BEMERKUNGEN:
- Man sollte diese Property sollte nicht per Hand veraendern, sondern
- die Funktionen AddSkill() bzw. AddSpell() nutzen.
+ P_GUILD_SKILLS "guild_skills"
-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
\ No newline at end of file
+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/props/P_GUILD_TITLE b/doc/props/P_GUILD_TITLE
index 4554349..d3a49b3 100644
--- a/doc/props/P_GUILD_TITLE
+++ b/doc/props/P_GUILD_TITLE
@@ -1,37 +1,58 @@
+
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.
+NAME
+====
-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.
+ P_GUILD_TITLE "guild_title"
-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
+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/props/P_HANDS b/doc/props/P_HANDS
index 9eda7c5..859b4eb 100644
--- a/doc/props/P_HANDS
+++ b/doc/props/P_HANDS
@@ -1,57 +1,78 @@
+
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)
+NAME
+====
- 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.
+ 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}) }));
+ 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.)
- Ein Saeurededaemon:
- SetProp(P_HANDS,
- ({
- " mit saeuretriefenden Klauen",
- 250,
- ({DT_RIP, DT_ACID})
- })
- );
+BEISPIEL
+========
- 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.
+ Ein starker Tausendfuessler mit Schlagschaden:
-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
+ 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/props/P_HANDS_USED_BY b/doc/props/P_HANDS_USED_BY
index dd0e5fe..f0d5165 100644
--- a/doc/props/P_HANDS_USED_BY
+++ b/doc/props/P_HANDS_USED_BY
@@ -1,21 +1,39 @@
+
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.
+NAME
+====
-BEMERKUNGEN:
- Darf nur ueber UseHands() und FreeHands() manipuliert werden.
+ P_HANDS_USED_BY "hands_used_by"
-SIEHE AUCH:
- P_HANDS
- P_MAX_HANDS, P_USED_HANDS, P_FREE_HANDS
- UseHands, FreeHands
+
+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/props/P_HARBOUR b/doc/props/P_HARBOUR
index c0e1048..f049847 100644
--- a/doc/props/P_HARBOUR
+++ b/doc/props/P_HARBOUR
@@ -1,66 +1,94 @@
-NAME:
- P_HARBOUR "harbour_name"
-DEFINIERT IN:
- /sys/transport.h
+P_HARBOUR
+*********
-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:
+NAME
+====
- ({ "zur Sonneninsel", ({"sonneninsel"}) }) oder
- ({ "nach Titiwu", ({"titiwu"}) })
+ P_HARBOUR "harbour_name"
- 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.
+DEFINIERT IN
+============
- 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'.
+ /sys/transport.h
-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.
+BESCHREIBUNG
+============
-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
+ Array mit eindeutiger Bezeichnung des 'Hafens'
-LETZTE AENDERUNG:
+
+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/props/P_HAUS_ERLAUBT b/doc/props/P_HAUS_ERLAUBT
index 8ac6495..ffd5c8f 100644
--- a/doc/props/P_HAUS_ERLAUBT
+++ b/doc/props/P_HAUS_ERLAUBT
@@ -1,29 +1,46 @@
-NAME:
- P_HAUS_ERLAUBT "haus_erlaubt"
-DEFINIERT IN:
- /sys/room/description.h
+P_HAUS_ERLAUBT
+**************
-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);
+NAME
+====
- 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.
+ P_HAUS_ERLAUBT "haus_erlaubt"
- Unter /doc/beispiele/misc liegt ein File, in dem dokumentiert ist,
- wie nach Aenderungen am Seherhaus zu verfahren ist.
-----------------------------------------------------------------------------
+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/props/P_HB b/doc/props/P_HB
index eee2dcb..bdaf9f1 100644
--- a/doc/props/P_HB
+++ b/doc/props/P_HB
@@ -1,9 +1,22 @@
-NAME:
- P_HB "hb"
-DEFINIERT IN:
- /sys/properties.h
+P_HB
+****
-BESCHREIBUNG:
- Diese Property wird gesetzt, wenn das Monster immer einen
- heart_beat haben soll. (VORSICHT, nur wenn es WIRKLICH sein muss!)
+
+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/props/P_HEAL b/doc/props/P_HEAL
index 242802f..83d4991 100644
--- a/doc/props/P_HEAL
+++ b/doc/props/P_HEAL
@@ -1,32 +1,48 @@
-NAME:
- P_HEAL "heal"
-DEFINIERT IN:
- /sys/properties.h
+P_HEAL
+******
-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.
+NAME
+====
- Die Gilden koennen P_HEAL abfragen und eigene, grobe Informationstexte
- ausgeben, die den Spieler ueber den zu erwartenden Effekt beim Essen
- einer Leiche informieren.
+ P_HEAL "heal"
- 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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- /std/corpse, QueryHealInfo()
-
+ /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/props/P_HELPER_NPC b/doc/props/P_HELPER_NPC
index eb71e47..af8bfef 100644
--- a/doc/props/P_HELPER_NPC
+++ b/doc/props/P_HELPER_NPC
@@ -1,30 +1,50 @@
+
P_HELPER_NPC
+************
-NAME:
- P_HELPER_NPC "std:helper_npc
-DEFINIERT IN:
- /sys/living/combat.h
+NAME
+====
-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]).
+ P_HELPER_NPC "std:helper_npc
- <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.
+DEFINIERT IN
+============
-BEISPIEL:
- s. RegisterHelperNPC().
+ /sys/living/combat.h
-SIEHE AUCH:
- RegisterHelperNPC(), UnregisterHelperNPC()
+
+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/props/P_HELPER_OBJECTS b/doc/props/P_HELPER_OBJECTS
index bdf031d..94990c4 100644
--- a/doc/props/P_HELPER_OBJECTS
+++ b/doc/props/P_HELPER_OBJECTS
@@ -1,25 +1,40 @@
+
P_HELPER_OBJECTS
+****************
-NAME:
- P_HELPER_OBJECTS "lib_p_helper_objects"
-DEFINIERT IN:
- <living/helpers.h>
+NAME
+====
-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 }) ]).
+ P_HELPER_OBJECTS "lib_p_helper_objects"
-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
+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/props/P_HIDE_EXITS b/doc/props/P_HIDE_EXITS
index 0c92a4a..c9aa2e5 100644
--- a/doc/props/P_HIDE_EXITS
+++ b/doc/props/P_HIDE_EXITS
@@ -1,35 +1,53 @@
+
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.
+NAME
+====
-BEISPIEL:
- AddExit("raus", "/ganz/wo/anders");
- AddExit("weiter", "/in/der/naehe");
+ P_HIDE_EXITS "hide_exits"
- // 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"}) );
+DEFINIERT IN
+============
- // Keinen Ausgang zeigen, aber den Text, dass keiner sichtbar, ausgeben.
- SetProp(P_HIDE_EXITS, ({"weiter", "raus"}) );
+ /sys/room/exits.h
-SIEHE AUCH:
- Aehnliches: P_SHOW_EXITS
- Sonstiges: AddExit(), GetExits(), int_long(), int_short()
-25. Apr 1996 Highlander
\ No newline at end of file
+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/props/P_HISTMIN b/doc/props/P_HISTMIN
index e84d90c..ca35504 100644
--- a/doc/props/P_HISTMIN
+++ b/doc/props/P_HISTMIN
@@ -1,8 +1,21 @@
-NAME:
- P_HISTMIN "histmin"
-DEFINIERT IN:
- /sys/player.h
+P_HISTMIN
+*********
-BESCHREIBUNG:
- Minimale Laenge, die eine Zeile haben muss, um in die History zu kommen
+
+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/props/P_HIT_FUNC b/doc/props/P_HIT_FUNC
index c5b3b31..9bcc328 100644
--- a/doc/props/P_HIT_FUNC
+++ b/doc/props/P_HIT_FUNC
@@ -1,22 +1,38 @@
+
P_HIT_FUNC
+**********
-NAME:
- P_HIT_FUNC "hit_func"
-DEFINIERT IN:
- <weapon.h>
+NAME
+====
-BESCHREIBUNG:
- Falls ein Objekt eine HitFunc() fuer die Waffe definiert, so muss
- dieses Objekt in dieser Property eingetragen werden.
+ P_HIT_FUNC "hit_func"
- Die Auswertung dieser Property erfolgt in QueryDamage().
-BEISPIELE:
- Siehe das Beispiel zu HitFunc()
+DEFINIERT IN
+============
-SIEHE AUCH:
- /std/weapon.c, HitFunc()
+ <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/props/P_HOMEPAGE b/doc/props/P_HOMEPAGE
index 7d90438..5cf6bec 100644
--- a/doc/props/P_HOMEPAGE
+++ b/doc/props/P_HOMEPAGE
@@ -1,8 +1,21 @@
-NAME:
- P_HOMEPAGE "homepage"
-DEFINIERT IN:
- /sys/player/base.h
+P_HOMEPAGE
+**********
-BESCHREIBUNG:
- Die Homepage eines Spielers (mit dem Befehl 'url' zu setzen).
+
+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/props/P_HP b/doc/props/P_HP
index f2aea74..b7ded4a 100644
--- a/doc/props/P_HP
+++ b/doc/props/P_HP
@@ -1,25 +1,39 @@
-NAME:
- P_HP "hp"
-DEFINIERT IN:
- /sys/living/life.h
+P_HP
+****
-BESCHREIBUNG:
- - Lebewesen
- Anzahl der Lebenspunkte des Wesens.
+NAME
+====
- - Speisen/Kneipen
- Heilwirkung einer Portion der Speise auf die Lebenspunkte
- des Konsumenten
+ P_HP "hp"
-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
\ No newline at end of file
+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/props/P_HP_DELAY b/doc/props/P_HP_DELAY
index a807ad9..f15f748 100644
--- a/doc/props/P_HP_DELAY
+++ b/doc/props/P_HP_DELAY
@@ -1,10 +1,23 @@
-NAME:
- P_HP_DELAY "hp_delay"
-DEFINIERT IN:
- /sys/living/life.h
+P_HP_DELAY
+**********
-BESCHREIBUNG:
- Anzahl der heart_beats, bis P_HP um einen Punkt regeneriert.
- Aenderungen dieser Property in Spielern beduerfen der
- Genehmigung des EM fuer Balance.
+
+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/props/P_HP_HOOKS b/doc/props/P_HP_HOOKS
index 28f1a1e..7bb48bf 100644
--- a/doc/props/P_HP_HOOKS
+++ b/doc/props/P_HP_HOOKS
@@ -1,19 +1,38 @@
-NAME:
- P_HP_HOOKS "hp_hooks"
-DEFINIERT IN:
- /sys/properties.h
+P_HP_HOOKS
+**********
-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.
+NAME
+====
-SIEHE AUCH:
- AddHpHook(), RemoveHpHook(),
- NotifyHpChange()
- std/hooks
+ 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/props/P_HUNTTIME b/doc/props/P_HUNTTIME
index 377ab18..e712a49 100644
--- a/doc/props/P_HUNTTIME
+++ b/doc/props/P_HUNTTIME
@@ -1,35 +1,59 @@
+
+P_HUNTTIME
+**********
+
+
P_HUNTTIME (int)
+================
-NAME:
- P_HUNTTIME "p_lib_hunttime"
-DEFINIERT IN:
- /sys/living/combat.h
+NAME
+====
-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).
+ P_HUNTTIME "p_lib_hunttime"
-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);
- }
+DEFINIERT IN
+============
-SIEHE AUCH:
- InsertSingleEnemy, InsertEnemy
- /std/living/combat.c
+ /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/props/P_IDS b/doc/props/P_IDS
index 311407b..dee9a74 100644
--- a/doc/props/P_IDS
+++ b/doc/props/P_IDS
@@ -1,25 +1,41 @@
+
P_IDS
+*****
-NAME:
- P_IDS "ids"
-DEFINIERT IN:
- <thing/description.h>
+NAME
+====
-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().
+ P_IDS "ids"
- 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!
+DEFINIERT IN
+============
-SIEHE AUCH:
- /std/thing/description.c, AddId(), RemoveId()
+ <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/props/P_IGNORE b/doc/props/P_IGNORE
index d95fd14..3436a09 100644
--- a/doc/props/P_IGNORE
+++ b/doc/props/P_IGNORE
@@ -1,22 +1,39 @@
-NAME:
- P_IGNORE "ignore"
-DEFINIERT IN:
- /sys/player/base.h
+P_IGNORE
+********
-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.
+NAME
+====
-SIEHE AUCH:
- TestIgnore, /std/player/comm.c
+ 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/props/P_INDOORS b/doc/props/P_INDOORS
index c1ab07a..4483d10 100644
--- a/doc/props/P_INDOORS
+++ b/doc/props/P_INDOORS
@@ -1,33 +1,52 @@
-NAME:
- P_INDOORS "indoors"
-DEFINIERT IN:
- /sys/room/description.h
+P_INDOORS
+*********
-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.
+NAME
+====
- Licht wird _nicht_ durch P_INDOORS beeinflusst, muss also
- selbst angepasst werden.
+ 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 dunkler Innenraum:
+ SetProp(P_INDOORS, 1); // ein Innenraum liegt innen :)
+ SetProp(P_LIGHT, 0); // Licht auf 0
- // Ein heller Aussenraum mit Mondlicht (gut fuer Delfen)
- SetProp(P_INDOORS, 0);
- SetProp(P_LIGHT, 1);
- SetProp(P_LIGHT_TYPE, LT_STARS|LT_MOON);
+ // 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
+==========
+
+ P_LIGHT, P_LIGHT_ABSORPTION, P_LIGHT_TYPE
25.Aug 2008 Gloinson
diff --git a/doc/props/P_INFO b/doc/props/P_INFO
index 06dabe6..f29c242 100644
--- a/doc/props/P_INFO
+++ b/doc/props/P_INFO
@@ -1,18 +1,36 @@
+
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")
+NAME
+====
-SIEHE AUCH:
- GetOwner(L)
+ P_INFO "info"
-24. April 2006, Vanion
+
+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/props/P_INFORMME b/doc/props/P_INFORMME
index 4736933..c6dd0ed 100644
--- a/doc/props/P_INFORMME
+++ b/doc/props/P_INFORMME
@@ -1,14 +1,30 @@
-NAME:
- P_INFORMME "informme"
-DEFINIERT IN:
- /sys/properties.h
+P_INFORMME
+**********
-BESCHREIBUNG:
- Enthaelt das Flag, ob der Spieler ueber ein-/ausloggende Spieler
- informiert werden will.
-SIEHE AUCH:
- Spielerkommando: inform
+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/props/P_INPC_HOME b/doc/props/P_INPC_HOME
index 31fea0b..1eafd4d 100644
--- a/doc/props/P_INPC_HOME
+++ b/doc/props/P_INPC_HOME
@@ -1,8 +1,21 @@
-NAME:
- P_INPC_HOME "inpc_home"
-DEFINIERT IN:
- /sys/inpc/walking.h
+P_INPC_HOME
+***********
-BESCHREIBUNG:
- *** KEINE BESCHREIBUNG VORHANDEN ***
+
+NAME
+====
+
+ P_INPC_HOME "inpc_home"
+
+
+DEFINIERT IN
+============
+
+ /sys/inpc/walking.h
+
+
+BESCHREIBUNG
+============
+
+ *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/props/P_INPC_LAST_ENVIRONMENT b/doc/props/P_INPC_LAST_ENVIRONMENT
index 2b7437a..8f7cb68 100644
--- a/doc/props/P_INPC_LAST_ENVIRONMENT
+++ b/doc/props/P_INPC_LAST_ENVIRONMENT
@@ -1,8 +1,21 @@
-NAME:
- P_INPC_LAST_ENVIRONMENT "inpc_last_environment"
-DEFINIERT IN:
- /sys/inpc/walking.h
+P_INPC_LAST_ENVIRONMENT
+***********************
-BESCHREIBUNG:
- *** KEINE BESCHREIBUNG VORHANDEN ***
+
+NAME
+====
+
+ P_INPC_LAST_ENVIRONMENT "inpc_last_environment"
+
+
+DEFINIERT IN
+============
+
+ /sys/inpc/walking.h
+
+
+BESCHREIBUNG
+============
+
+ *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/props/P_INPC_LAST_PLAYER_CONTACT b/doc/props/P_INPC_LAST_PLAYER_CONTACT
index f32cd02..14f8730 100644
--- a/doc/props/P_INPC_LAST_PLAYER_CONTACT
+++ b/doc/props/P_INPC_LAST_PLAYER_CONTACT
@@ -1,8 +1,21 @@
-NAME:
- P_INPC_LAST_PLAYER_CONTACT "inpc_last_player_contact"
-DEFINIERT IN:
- /sys/inpc/walking.h
+P_INPC_LAST_PLAYER_CONTACT
+**************************
-BESCHREIBUNG:
- *** KEINE BESCHREIBUNG VORHANDEN ***
+
+NAME
+====
+
+ P_INPC_LAST_PLAYER_CONTACT "inpc_last_player_contact"
+
+
+DEFINIERT IN
+============
+
+ /sys/inpc/walking.h
+
+
+BESCHREIBUNG
+============
+
+ *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/props/P_INPC_WALK_AREA b/doc/props/P_INPC_WALK_AREA
index 3d7dfc6..9554d27 100644
--- a/doc/props/P_INPC_WALK_AREA
+++ b/doc/props/P_INPC_WALK_AREA
@@ -1,8 +1,21 @@
-NAME:
- P_INPC_WALK_AREA "inpc_walk_area"
-DEFINIERT IN:
- /sys/inpc/walking.h
+P_INPC_WALK_AREA
+****************
-BESCHREIBUNG:
- *** KEINE BESCHREIBUNG VORHANDEN ***
+
+NAME
+====
+
+ P_INPC_WALK_AREA "inpc_walk_area"
+
+
+DEFINIERT IN
+============
+
+ /sys/inpc/walking.h
+
+
+BESCHREIBUNG
+============
+
+ *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/props/P_INPC_WALK_DELAYS b/doc/props/P_INPC_WALK_DELAYS
index f510764..e59deea 100644
--- a/doc/props/P_INPC_WALK_DELAYS
+++ b/doc/props/P_INPC_WALK_DELAYS
@@ -1,8 +1,21 @@
-NAME:
- P_INPC_WALK_DELAYS "inpc_walk_delay"
-DEFINIERT IN:
- /sys/inpc/walking.h
+P_INPC_WALK_DELAYS
+******************
-BESCHREIBUNG:
- *** KEINE BESCHREIBUNG VORHANDEN ***
+
+NAME
+====
+
+ P_INPC_WALK_DELAYS "inpc_walk_delay"
+
+
+DEFINIERT IN
+============
+
+ /sys/inpc/walking.h
+
+
+BESCHREIBUNG
+============
+
+ *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/props/P_INPC_WALK_FLAGS b/doc/props/P_INPC_WALK_FLAGS
index 3e8749b..86c4835 100644
--- a/doc/props/P_INPC_WALK_FLAGS
+++ b/doc/props/P_INPC_WALK_FLAGS
@@ -1,8 +1,21 @@
-NAME:
- P_INPC_WALK_FLAGS "inpc_walk_flags"
-DEFINIERT IN:
- /sys/inpc/walking.h
+P_INPC_WALK_FLAGS
+*****************
-BESCHREIBUNG:
- *** KEINE BESCHREIBUNG VORHANDEN ***
+
+NAME
+====
+
+ P_INPC_WALK_FLAGS "inpc_walk_flags"
+
+
+DEFINIERT IN
+============
+
+ /sys/inpc/walking.h
+
+
+BESCHREIBUNG
+============
+
+ *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/props/P_INPC_WALK_MODE b/doc/props/P_INPC_WALK_MODE
index 22da99d..134bb50 100644
--- a/doc/props/P_INPC_WALK_MODE
+++ b/doc/props/P_INPC_WALK_MODE
@@ -1,8 +1,21 @@
-NAME:
- P_INPC_WALK_MODE "inpc_walk_mode"
-DEFINIERT IN:
- /sys/inpc/walking.h
+P_INPC_WALK_MODE
+****************
-BESCHREIBUNG:
- *** KEINE BESCHREIBUNG VORHANDEN ***
+
+NAME
+====
+
+ P_INPC_WALK_MODE "inpc_walk_mode"
+
+
+DEFINIERT IN
+============
+
+ /sys/inpc/walking.h
+
+
+BESCHREIBUNG
+============
+
+ *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/props/P_INPC_WALK_ROUTE b/doc/props/P_INPC_WALK_ROUTE
index 4d11cb1..762408d 100644
--- a/doc/props/P_INPC_WALK_ROUTE
+++ b/doc/props/P_INPC_WALK_ROUTE
@@ -1,8 +1,21 @@
-NAME:
- P_INPC_WALK_ROUTE "inpc_walk_route"
-DEFINIERT IN:
- /sys/inpc/walking.h
+P_INPC_WALK_ROUTE
+*****************
-BESCHREIBUNG:
- *** KEINE BESCHREIBUNG VORHANDEN ***
+
+NAME
+====
+
+ P_INPC_WALK_ROUTE "inpc_walk_route"
+
+
+DEFINIERT IN
+============
+
+ /sys/inpc/walking.h
+
+
+BESCHREIBUNG
+============
+
+ *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/props/P_INTERMUD b/doc/props/P_INTERMUD
index 6d4bd59..8019998 100644
--- a/doc/props/P_INTERMUD
+++ b/doc/props/P_INTERMUD
@@ -1,13 +1,25 @@
-NAME:
- P_INTERMUD "intermud"
-DEFINIERT IN:
- /sys/player/comm.h
+P_INTERMUD
+**********
-BESCHREIBUNG:
+
+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/props/P_INTERNAL_EXTRA_LOOK b/doc/props/P_INTERNAL_EXTRA_LOOK
index 160125d..ffa78ad 100644
--- a/doc/props/P_INTERNAL_EXTRA_LOOK
+++ b/doc/props/P_INTERNAL_EXTRA_LOOK
@@ -1,39 +1,57 @@
-NAME:
- P_INTERNAL_EXTRA_LOOK "internal_extralook"
-DEFINIERT IN:
- /sys/living/description.h
+P_INTERNAL_EXTRA_LOOK
+*********************
-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.
+NAME
+====
-SIEHE AUCH:
- long(), /std/living/description.c, /std/player/base.c
- AddExtraLook(), RemoveExtraLook()
+ 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/props/P_INT_LIGHT b/doc/props/P_INT_LIGHT
index 04504a6..dcf59b6 100644
--- a/doc/props/P_INT_LIGHT
+++ b/doc/props/P_INT_LIGHT
@@ -1,20 +1,36 @@
-NAME:
- P_INT_LIGHT "int_light"
-DEFINIERT IN:
- /sys/properties.h
+P_INT_LIGHT
+***********
-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!
+NAME
+====
- Ein direktes setzen dieser Property ist NICHT moeglich, hierzu bitte
- P_LIGHT benutzen!
+ P_INT_LIGHT "int_light"
-SIEHE AUCH:
- P_LIGHT, P_TOTAL_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
+
+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/props/P_INT_LONG b/doc/props/P_INT_LONG
index 3e59249..741e511 100644
--- a/doc/props/P_INT_LONG
+++ b/doc/props/P_INT_LONG
@@ -1,32 +1,53 @@
+
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.
+NAME
+====
- Der Text sollte bereits umgebrochen sein.
+ P_INT_LONG "int_long"
- 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.)
+DEFINIERT IN
+============
-BEISPIELE:
- SetProp(P_INT_LONG, break_string(
- "Du stehst in einem total spannenden Testraum. Seine absolute "
- "Nichtigkeit erfuellt dich mit ehrfuerchtigem Grauen.",78));
+ /sys/room/description.h
-SIEHE AUCH:
- Aehnliches: P_INT_SHORT
- Sonstiges: int_long(), P_LONG
- process_string(), break_string()
+
+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/props/P_INT_SHORT b/doc/props/P_INT_SHORT
index 9c6a0af..618bbab 100644
--- a/doc/props/P_INT_SHORT
+++ b/doc/props/P_INT_SHORT
@@ -1,36 +1,56 @@
+
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).
+NAME
+====
- 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).
+ P_INT_SHORT "int_short"
- 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.
+DEFINIERT IN
+============
-BEMERKUNGEN:
- - int_short() (bei Bewegung) filtert P_INT_SHORT durch process_string()
- -> daher sind Closures moeglich
+ /sys/thing/description.h
-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()
+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/props/P_INVIS b/doc/props/P_INVIS
index 7022ea0..4063546 100644
--- a/doc/props/P_INVIS
+++ b/doc/props/P_INVIS
@@ -1,50 +1,65 @@
-NAME:
- P_INVIS "invis"
-DEFINIERT IN:
- /sys/player/base.h
+P_INVIS
+*******
-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.
+NAME
+====
- - 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.
+ 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/props/P_IP_NAME b/doc/props/P_IP_NAME
index 7b503ea..6003c80 100644
--- a/doc/props/P_IP_NAME
+++ b/doc/props/P_IP_NAME
@@ -1,8 +1,21 @@
-NAME:
- P_IP_NAME "ip_name"
-DEFINIERT IN:
- /sys/player.h
+P_IP_NAME
+*********
-BESCHREIBUNG:
- Rechnername des Interactives
+
+NAME
+====
+
+ P_IP_NAME "ip_name"
+
+
+DEFINIERT IN
+============
+
+ /sys/player.h
+
+
+BESCHREIBUNG
+============
+
+ Rechnername des Interactives
diff --git a/doc/props/P_IS_ARTILLERY b/doc/props/P_IS_ARTILLERY
index 051b20f..2afcd60 100644
--- a/doc/props/P_IS_ARTILLERY
+++ b/doc/props/P_IS_ARTILLERY
@@ -1,15 +1,30 @@
-NAME:
- P_IS_ARTILLERY "artillery"
-DEFINIERT IN:
- /sys/combat.h
+P_IS_ARTILLERY
+**************
-BESCHREIBUNG:
- Is ein Objekt Artillerie, so muss diese Property
- gesetzt sein. (Derzeit einfach auf 1 setzen.)
-SIEHE AUCH:
- artillerie
+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/props/P_ITEMS b/doc/props/P_ITEMS
index add4255..1fcafc5 100644
--- a/doc/props/P_ITEMS
+++ b/doc/props/P_ITEMS
@@ -1,9 +1,22 @@
-NAME:
- P_ITEMS "items"
-DEFINIERT IN:
- /sys/properties.h
+P_ITEMS
+*******
-BESCHREIBUNG:
- Definition von Gegenstaenden, die in dem Raum liegen sollen.
- Erklaerung in einem Extrafile.
+
+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/props/P_I_HATE_ALCOHOL b/doc/props/P_I_HATE_ALCOHOL
index f60a38f..0a0eefc 100644
--- a/doc/props/P_I_HATE_ALCOHOL
+++ b/doc/props/P_I_HATE_ALCOHOL
@@ -1,23 +1,41 @@
-NAME:
- P_I_HATE_ALCOHOL "i_hate_alcohol"
-DEFINIERT IN:
- /sys/inpc/boozing.h
+P_I_HATE_ALCOHOL
+****************
-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.
+NAME
+====
-SIEHE AUCH:
- P_ALCOHOL, P_MAX_ALCOHOL
+ 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/props/P_KEEPER b/doc/props/P_KEEPER
index c0275ba..63185c8 100644
--- a/doc/props/P_KEEPER
+++ b/doc/props/P_KEEPER
@@ -1,14 +1,26 @@
-NAME:
- P_KEEPER "shop_keeper"
-DEFINIERT IN:
- /sys/properties.h
+P_KEEPER
+********
-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
\ No newline at end of file
+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/props/P_KEEP_ON_SELL b/doc/props/P_KEEP_ON_SELL
index 8a21407..ce5feba 100644
--- a/doc/props/P_KEEP_ON_SELL
+++ b/doc/props/P_KEEP_ON_SELL
@@ -1,8 +1,21 @@
-NAME:
- P_KEEP_ON_SELL "keep_on_sell"
-DEFINIERT IN:
- /sys/properties.h
+P_KEEP_ON_SELL
+**************
-BESCHREIBUNG:
- Bei "verkaufe alles" wird das Objekt behalten.
+
+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/props/P_KILLER b/doc/props/P_KILLER
index 83f6b18..01bb0d1 100644
--- a/doc/props/P_KILLER
+++ b/doc/props/P_KILLER
@@ -1,10 +1,23 @@
-NAME:
- P_KILLER "killer"
-DEFINIERT IN:
- /sys/properties.h
+P_KILLER
+********
-BESCHREIBUNG:
+
+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
@@ -16,12 +29,18 @@
waehrend eines NotifyPlayerDeath(), weil es evtl. noch andere Objekte gibt,
die sich dafuer interessieren!
-BEMERKUNGEN:
+
+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:
+
+SIEHE AUCH
+==========
+
do_damage()
29.08.2008, Zesstra
diff --git a/doc/props/P_KILLS b/doc/props/P_KILLS
index 3dae72d..7ec3dac 100644
--- a/doc/props/P_KILLS
+++ b/doc/props/P_KILLS
@@ -1,10 +1,23 @@
-NAME:
- P_KILLS "playerkills"
-DEFINIERT IN:
- /sys/properties.h
+P_KILLS
+*******
-BESCHREIBUNG:
- Anzahl der Spieler, die dieser Spieler schon getoetet hat.
- Unerlaubte Manipulation ist ein SCHWERES VERGEHEN gegen
- die Mudreglen.
+
+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/props/P_KILL_MSG b/doc/props/P_KILL_MSG
index 0a9e3bb..9437975 100644
--- a/doc/props/P_KILL_MSG
+++ b/doc/props/P_KILL_MSG
@@ -1,80 +1,96 @@
+
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:
+NAME
+====
- 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.]
+ P_KILL_MSG "kill_msg"
- Weiteres Beispiel.
- Man habe einen NPC, dessen Killname als Plural aufzufassen ist, der aber
- keinen zusaetlichen Text auf -Tod bringen soll.
+DEFINIERT IN
+============
- SetProp(P_NAME, "Eine Horde Gummibaeren");
- SetProp(P_KILL_NAME, "Viele kleine Gummibaeren");
- SetProp(P_KILL_MSG, ({0, 0, 1}));
+ /sys/properties.h
-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
-----------------------------------------------------------------------------
+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/props/P_KILL_NAME b/doc/props/P_KILL_NAME
index 3f214ab..0504066 100644
--- a/doc/props/P_KILL_NAME
+++ b/doc/props/P_KILL_NAME
@@ -1,43 +1,59 @@
+
P_KILL_NAME
+***********
-NAME:
- P_KILL_NAME "kill_name"
-DEFINIERT IN:
- /sys/properties.h
+NAME
+====
-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.
+ P_KILL_NAME "kill_name"
-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");
- ...
- }
+DEFINIERT IN
+============
-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
+ /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/props/P_KNOWN_POTIONROOMS b/doc/props/P_KNOWN_POTIONROOMS
index f5adb97..29e17d3 100644
--- a/doc/props/P_KNOWN_POTIONROOMS
+++ b/doc/props/P_KNOWN_POTIONROOMS
@@ -1,19 +1,35 @@
-NAME:
- P_KNOWN_POTIONROOMS "known_potionrooms"
-DEFINIERT IN:
- /sys/player/potion.h
+P_KNOWN_POTIONROOMS
+*******************
-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.
+NAME
+====
-SIEHE AUCH:
- Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
- Verwandt: FindPotion(), AddKnownPotion(), RemoveKnownPotion(), InList()
- Props: P_POTIONROOMS
+ 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/props/P_LASTDIR b/doc/props/P_LASTDIR
index eae9071..2695f06 100644
--- a/doc/props/P_LASTDIR
+++ b/doc/props/P_LASTDIR
@@ -1,15 +1,28 @@
-NAME:
- P_LASTDIR "p_lib_lastdir"
-DEFINIERT IN:
- /sys/shells.h
+P_LASTDIR
+*********
-BESCHREIBUNG:
- Das jeweils letzte Verzeichnis, in dem der Magier war.
- (Nur fuer Magier von Belang)
+
+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
+ P_CURRENTDIR
Letzte Aenderung:
- 03.05.2016, Zesstra
+ 03.05.2016, Zesstra
diff --git a/doc/props/P_LAST_COMBAT_TIME b/doc/props/P_LAST_COMBAT_TIME
index b3df96d..941ec1e 100644
--- a/doc/props/P_LAST_COMBAT_TIME
+++ b/doc/props/P_LAST_COMBAT_TIME
@@ -1,23 +1,38 @@
-NAME:
- P_LAST_COMBAT_TIME "last_combat_time"
-DEFINIERT IN:
- /sys/combat.h
+P_LAST_COMBAT_TIME
+******************
-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
+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/props/P_LAST_COMMAND_ENV b/doc/props/P_LAST_COMMAND_ENV
index 576e34d..40bd6a0 100644
--- a/doc/props/P_LAST_COMMAND_ENV
+++ b/doc/props/P_LAST_COMMAND_ENV
@@ -1,15 +1,30 @@
+
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.
+NAME
+====
-BEMERKUNGEN:
- Keine echte Property, _query_last_command_env() ist
- in /std/players/command.c implementiert.
+ 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/props/P_LAST_CONTENT_CHANGE b/doc/props/P_LAST_CONTENT_CHANGE
index 0fa64bb..f128774 100644
--- a/doc/props/P_LAST_CONTENT_CHANGE
+++ b/doc/props/P_LAST_CONTENT_CHANGE
@@ -1,16 +1,32 @@
-NAME:
- P_LAST_CONTENT_CHANGE "last_content_change"
-DEFINIERT IN:
- /sys/properties.h
+P_LAST_CONTENT_CHANGE
+*********************
-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*.
+NAME
+====
- Ausserdem fuehrt ein Setzen per SetProp() zu einer Erhoehung des
- Wertes um eins - unabhaengig vom gesetzten Wert.
+ 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/props/P_LAST_DAMAGE b/doc/props/P_LAST_DAMAGE
index 8d618b1..66388b7 100644
--- a/doc/props/P_LAST_DAMAGE
+++ b/doc/props/P_LAST_DAMAGE
@@ -1,22 +1,37 @@
-NAME:
- P_LAST_DAMAGE "last_damage"
-DEFINIERT IN:
- /sys/living/combat.h
+P_LAST_DAMAGE
+*************
-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
+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/props/P_LAST_DAMTIME b/doc/props/P_LAST_DAMTIME
index 72ffb51..7e6d0ea 100644
--- a/doc/props/P_LAST_DAMTIME
+++ b/doc/props/P_LAST_DAMTIME
@@ -1,22 +1,37 @@
-NAME:
- P_LAST_DAMTIME "last_damtime"
-DEFINIERT IN:
- /sys/living/combat.h
+P_LAST_DAMTIME
+**************
-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
+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/props/P_LAST_DAMTYPES b/doc/props/P_LAST_DAMTYPES
index 9d7b060..ecdf571 100644
--- a/doc/props/P_LAST_DAMTYPES
+++ b/doc/props/P_LAST_DAMTYPES
@@ -1,21 +1,36 @@
-NAME:
- P_LAST_DAMTYPES "last_damtypes"
-DEFINIERT IN:
- /sys/living/combat.h
+P_LAST_DAMTYPES
+***************
-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
+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/props/P_LAST_DEATH_PROPS b/doc/props/P_LAST_DEATH_PROPS
index 712e04e..7249dad 100644
--- a/doc/props/P_LAST_DEATH_PROPS
+++ b/doc/props/P_LAST_DEATH_PROPS
@@ -1,18 +1,32 @@
-NAME:
- P_LAST_DEATH_PROPS "last_death_props"
-DEFINIERT IN:
- /sys/living/life.h
+P_LAST_DEATH_PROPS
+******************
-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.
+NAME
+====
- 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
+ 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/props/P_LAST_DEATH_TIME b/doc/props/P_LAST_DEATH_TIME
index 71bd787..669e7a1 100644
--- a/doc/props/P_LAST_DEATH_TIME
+++ b/doc/props/P_LAST_DEATH_TIME
@@ -1,8 +1,21 @@
-NAME:
- P_LAST_DEATH_TIME "last_death_time"
-DEFINIERT IN:
- /sys/living/life.h
+P_LAST_DEATH_TIME
+*****************
-BESCHREIBUNG:
- Der Zeitpunkt des letzten Todes des Spielers.
+
+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/props/P_LAST_LOGIN b/doc/props/P_LAST_LOGIN
index 9287654..4ad7360 100644
--- a/doc/props/P_LAST_LOGIN
+++ b/doc/props/P_LAST_LOGIN
@@ -1,16 +1,35 @@
-NAME:
- P_LAST_LOGIN "last_login"
-DEFINIERT IN:
- /sys/player/base.h
+P_LAST_LOGIN
+************
-BESCHREIBUNG:
- Zeitpunkt des letzten Logins
-BEMERKUNGEN:
- Gegen aeussere Aenderung und Set/QueryMethoden geschuetzt.
+NAME
+====
-SIEHE AUCH:
- P_LAST_LOGOUT, save_me
+ 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/props/P_LAST_LOGOUT b/doc/props/P_LAST_LOGOUT
index 296ae92..e94e89e 100644
--- a/doc/props/P_LAST_LOGOUT
+++ b/doc/props/P_LAST_LOGOUT
@@ -1,20 +1,39 @@
-NAME:
- P_LAST_LOGOUT "last_logout"
-DEFINIERT IN:
- /sys/player/base.h
+P_LAST_LOGOUT
+*************
-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.
+NAME
+====
-BEMERKUNGEN:
- Gegen aeussere Aenderung und Set/QueryMethoden geschuetzt.
+ P_LAST_LOGOUT "last_logout"
-SIEHE AUCH:
- P_LAST_LOGIN, P_INVIS, save_me, init, StopHuntFor
+
+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/props/P_LAST_MOVE b/doc/props/P_LAST_MOVE
index 6b202a2..f6c974a 100644
--- a/doc/props/P_LAST_MOVE
+++ b/doc/props/P_LAST_MOVE
@@ -1,21 +1,36 @@
-NAME:
- P_LAST_MOVE "last_move"
-DEFINIERT IN:
- /sys/thing/moving.h
+P_LAST_MOVE
+***********
-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
+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/props/P_LAST_USE b/doc/props/P_LAST_USE
index 5ca875d..57519c9 100644
--- a/doc/props/P_LAST_USE
+++ b/doc/props/P_LAST_USE
@@ -1,20 +1,33 @@
+
P_LAST_USE
+**********
-NAME:
- P_LAST_USE "last_use"
-DEFINIERT IN:
- <properties.h>
+NAME
+====
-BESCHREIBUNG:
- Diese Property wird in Ruestungen und Waffen dazu benutzt um
- festzuhalten, wann die Ruestung/Waffe zuletzt im Kampf benutzt
- wurde.
+ P_LAST_USE "last_use"
-SIEHE AUCH:
- Ruestungen: QueryDefend(L)
- Waffen: QueryDamage(L)
- Sonstiges: P_EQUIP_TIME, P_UNWIELD_TIME
-----------------------------------------------------------------------------
+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/props/P_LAST_WEAR_ACTION b/doc/props/P_LAST_WEAR_ACTION
index 1a4d224..5531955 100644
--- a/doc/props/P_LAST_WEAR_ACTION
+++ b/doc/props/P_LAST_WEAR_ACTION
@@ -1,24 +1,31 @@
-PROPERTY:
- P_LAST_WEAR_ACTION "last_wear_action"
+P_LAST_WEAR_ACTION
+******************
-DEFINIERT IN:
- /sys/armour.h (und damit auch in properties.h)
+PROPERTY
+========
-BESCHREIBUNG:
+ P_LAST_WEAR_ACTION "last_wear_action"
- 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.
+DEFINIERT IN:
- 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.
+ /sys/armour.h (und damit auch in properties.h)
-LETZTE AENDERUNG:
+
+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/props/P_LAST_XP b/doc/props/P_LAST_XP
index e5ee055..c31a8b4 100644
--- a/doc/props/P_LAST_XP
+++ b/doc/props/P_LAST_XP
@@ -1,27 +1,43 @@
-NAME:
- P_LAST_XP "last_xp"
-DEFINIERT IN:
- /sys/living/life.h
+P_LAST_XP
+*********
-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".
+NAME
+====
- 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.
+ P_LAST_XP "last_xp"
- 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
+DEFINIERT IN
+============
-14.Feb 2007 Gloinson
\ No newline at end of file
+ /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/props/P_LEAVECMDS b/doc/props/P_LEAVECMDS
index e31cf8a..5b0e03c 100644
--- a/doc/props/P_LEAVECMDS
+++ b/doc/props/P_LEAVECMDS
@@ -1,32 +1,56 @@
-NAME:
- P_LEAVECMDS "leavecmds"
-DEFINIERT IN:
- /sys/transport.h
+P_LEAVECMDS
+***********
-BESCHREIBUNG:
- Ein Array mit Befehlen, die zum Verlassen des Transporters fuehren.
-BEISPIEL:
- SetProp(P_LEAVECMDS,({ "verlass","verlasse" }) );
+NAME
+====
- 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.
+ P_LEAVECMDS "leavecmds"
-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.
+DEFINIERT IN
+============
- Sollen Kommandos zum Betreten UND Verlassen eines Transporters ver-
- wendet werden koennen, muessen diese in P_TRAVEL_CMDS gesetzt werden.
+ /sys/transport.h
-SIEHE AUCH:
- P_LEAVEFAIL, P_ENTERFAIL, P_ENTERCMDS, P_TRAVEL_CMDS, transporter,
-LETZTE AENDERUNG:
- Don, 24.01.2002, 10:15:07h von Tilly
-
\ No newline at end of file
+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/props/P_LEAVEFAIL b/doc/props/P_LEAVEFAIL
index a54b4a1..88e92ea 100644
--- a/doc/props/P_LEAVEFAIL
+++ b/doc/props/P_LEAVEFAIL
@@ -1,26 +1,48 @@
-NAME:
- P_LEAVEFAIL "leavefail"
-DEFINIERT IN:
- /sys/transport.h
+P_LEAVEFAIL
+***********
-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" );
+NAME
+====
- 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
+ P_LEAVEFAIL "leavefail"
-LETZTE AENDERUNG:
- Don, 24.01.2002, 10:15:07h von Tilly
+
+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/props/P_LEAVEMSG b/doc/props/P_LEAVEMSG
index 592bbc4..a3a1baf 100644
--- a/doc/props/P_LEAVEMSG
+++ b/doc/props/P_LEAVEMSG
@@ -1,19 +1,38 @@
-NAME:
- P_LEAVEMSG "leavemsg"
-DEFINIERT IN:
- /sys/transport.h
+P_LEAVEMSG
+**********
-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" }) );
+NAME
+====
-SIEHE AUCH:
- P_ENTERMSG, P_LEAVEFAIL, P_ENTERFAIL, transporter
+ P_LEAVEMSG "leavemsg"
-LETZTE AENDERUNG:
- Don, 24.01.2002, 10:15:07h von Tilly
+
+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/props/P_LEP b/doc/props/P_LEP
index 7628b1c..dbcea68 100644
--- a/doc/props/P_LEP
+++ b/doc/props/P_LEP
@@ -1,9 +1,22 @@
-NAME:
- P_LEP "lep"
-DEFINIERT IN:
- /sys/player.h
+P_LEP
+*****
-BESCHREIBUNG:
- Levelpunkte eines Spielers
- NICHT VON HAND SETZEN!!!
+
+NAME
+====
+
+ P_LEP "lep"
+
+
+DEFINIERT IN
+============
+
+ /sys/player.h
+
+
+BESCHREIBUNG
+============
+
+ Levelpunkte eines Spielers
+ NICHT VON HAND SETZEN!!!
diff --git a/doc/props/P_LEVEL b/doc/props/P_LEVEL
index 40be5d0..a4b804c 100644
--- a/doc/props/P_LEVEL
+++ b/doc/props/P_LEVEL
@@ -1,33 +1,48 @@
-NAME:
- P_LEVEL "level"
-DEFINIERT IN:
- /sys/living/description.h
+P_LEVEL
+*******
-BESCHREIBUNG:
- Spieler-Level (!= Magierlevel)
+NAME
+====
- 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.
+ P_LEVEL "level"
- 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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- Properties: P_GUILD_LEVEL
- Allgemeines: /doc/wiz/gift, /doc/help/gift
- Funktionen: AddClass(L), is_class_member(L)
+ /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/props/P_LIFETIME b/doc/props/P_LIFETIME
index 250c287..4c76f14 100644
--- a/doc/props/P_LIFETIME
+++ b/doc/props/P_LIFETIME
@@ -1,30 +1,51 @@
-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
\ No newline at end of file
+
+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/props/P_LIGHT b/doc/props/P_LIGHT
index 251e927..d0b55d8 100644
--- a/doc/props/P_LIGHT
+++ b/doc/props/P_LIGHT
@@ -1,62 +1,81 @@
-NAME:
- P_LIGHT "light"
-DEFINIERT IN:
- /sys/properties.h
+P_LIGHT
+*******
-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!
+NAME
+====
-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.
+ P_LIGHT "light"
- 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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- P_TOTAL_LIGHT, P_INT_LIGHT, P_PLAYER_LIGHT, P_LIGHT_MODIFIER, CannotSee()
+ /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/props/P_LIGHTDESC b/doc/props/P_LIGHTDESC
index 5898db8..e8c52d1 100644
--- a/doc/props/P_LIGHTDESC
+++ b/doc/props/P_LIGHTDESC
@@ -1,34 +1,56 @@
-NAME:
- P_LIGHTDESC "lightdesc"
-DEFINIERT IN:
- /sys/properties.h
+P_LIGHTDESC
+***********
-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).
+NAME
+====
-BEISPIELE:
- Eine einfache Oellampe:
+ P_LIGHTDESC "lightdesc"
- SetProp(P_LIGHTDESC, "angezuendet");
- Eine Fackel mit mehreren Brennstadien (aus /items/fackel.c):
+DEFINIERT IN
+============
- SetProp(P_LIGHTDESC, ({"glimmend","flackernd","leicht flackernd",
- "brennend","hell lodernd","frisch angezuendet"}));
+ /sys/properties.h
-SIEHE AUCH:
- Basisklassen: /std/lightsource.c
- Properties: P_FUEL, P_DO_DESTRUCT, P_LIGHT
- Methoden: AddFuel(L)
-LETZTE AENDERUNG:
- 22. Dez. 2015, Arathorn
+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/props/P_LIGHTED b/doc/props/P_LIGHTED
index 9029b02..31d7709 100644
--- a/doc/props/P_LIGHTED
+++ b/doc/props/P_LIGHTED
@@ -1,8 +1,21 @@
-NAME:
- P_LIGHTED "lighted"
-DEFINIERT IN:
- /sys/properties.h
+P_LIGHTED
+*********
-BESCHREIBUNG:
- Flag, ob die Lichtquelle in Betrieb ist.
+
+NAME
+====
+
+ P_LIGHTED "lighted"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ Flag, ob die Lichtquelle in Betrieb ist.
diff --git a/doc/props/P_LIGHT_ABSORPTION b/doc/props/P_LIGHT_ABSORPTION
index 213120f..4443a98 100644
--- a/doc/props/P_LIGHT_ABSORPTION
+++ b/doc/props/P_LIGHT_ABSORPTION
@@ -1,15 +1,31 @@
-NAME:
- P_LIGHT_ABSORPTION "light_absorption"
-DEFINIERT IN:
- /sys/room/description.h
+P_LIGHT_ABSORPTION
+******************
-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()
+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/props/P_LIGHT_MODIFIER b/doc/props/P_LIGHT_MODIFIER
index 2409c79..c7741ee 100644
--- a/doc/props/P_LIGHT_MODIFIER
+++ b/doc/props/P_LIGHT_MODIFIER
@@ -1,49 +1,75 @@
-NAME:
- P_LIGHT_MODIFIER "light_modifier"
-DEFINIERT IN:
- /sys/properties.h
+P_LIGHT_MODIFIER
+****************
-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.
+NAME
+====
-BEISPIELE:
- // Ein NPC der auch in relativ dunklen Raeumen mit Lichtlevel -2
- // noch sehen kann...
- create_default_npc(10);
- SetProp(P_LIGHT_MODIFIER, 3);
+ P_LIGHT_MODIFIER "light_modifier"
- // Eine Sonnenbrille, die das Lichtlevel um eins senkt.
- create()
- {
- :
- SetProp(P_ARMOUR_TYPE, AT_GLASSES);
- SetProp(P_LIGHT_MODIFIER, -1);
- :
- }
+DEFINIERT IN
+============
- // 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);
- }
+ /sys/properties.h
- 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()
+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/props/P_LIGHT_TRANSPARENCY b/doc/props/P_LIGHT_TRANSPARENCY
index 4af4415..42d0d13 100644
--- a/doc/props/P_LIGHT_TRANSPARENCY
+++ b/doc/props/P_LIGHT_TRANSPARENCY
@@ -1,14 +1,30 @@
-NAME:
- P_LIGHT_TRANSPARENCY "light_transparency"
-DEFINIERT IN:
- /sys/container.h
+P_LIGHT_TRANSPARENCY
+********************
-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()
+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/props/P_LIGHT_TYPE b/doc/props/P_LIGHT_TYPE
index 07322e0..47abbf4 100644
--- a/doc/props/P_LIGHT_TYPE
+++ b/doc/props/P_LIGHT_TYPE
@@ -1,75 +1,106 @@
-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.
+P_LIGHT_TYPE
+************
-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.
+NAME
+====
- 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.
+ P_LIGHT_TYPE "light_type"
-SIEHE AUCH:
- CheckLightType, /std/thing/description.h, operators
+
+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/props/P_LIQUID b/doc/props/P_LIQUID
index 1631a8e..55672bb 100644
--- a/doc/props/P_LIQUID
+++ b/doc/props/P_LIQUID
@@ -1,8 +1,21 @@
-NAME:
- P_LIQUID "w_max_wasserfuellmenge"
-DEFINIERT IN:
- /sys/fishing.h
+P_LIQUID
+********
-BESCHREIBUNG:
- *** KEINE BESCHREIBUNG VORHANDEN ***
+
+NAME
+====
+
+ P_LIQUID "w_max_wasserfuellmenge"
+
+
+DEFINIERT IN
+============
+
+ /sys/fishing.h
+
+
+BESCHREIBUNG
+============
+
+ *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/props/P_LOCALCMDS b/doc/props/P_LOCALCMDS
index 5a7b515..02a3c2a 100644
--- a/doc/props/P_LOCALCMDS
+++ b/doc/props/P_LOCALCMDS
@@ -1,12 +1,25 @@
-NAME:
- P_LOCALCMDS "localcmds"
-DEFINIERT IN:
- /sys/properties.h
+P_LOCALCMDS
+***********
-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).
+
+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/props/P_LOCATION b/doc/props/P_LOCATION
index 97344d8..cf2ed6c 100644
--- a/doc/props/P_LOCATION
+++ b/doc/props/P_LOCATION
@@ -1,19 +1,32 @@
-NAME:
- P_LOCATION "location"
-DEFINIERT IN:
- /sys/player/base.h
+P_LOCATION
+**********
-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
-----------------------------------------------------------------------------
+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/props/P_LOG_INFO b/doc/props/P_LOG_INFO
index b6bd8dc..0ed186d 100644
--- a/doc/props/P_LOG_INFO
+++ b/doc/props/P_LOG_INFO
@@ -1,32 +1,55 @@
-NAME:
- P_LOG_INFO "log_info"
-DEFINIERT IN:
- /sys/properties.h
+P_LOG_INFO
+**********
-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.
+NAME
+====
-BEISPIELE:
- SetProp(P_LOG_INFO,1); // Alle fehlenden Infos dieses
- Monsters werden in das Report-
- File unter /log/report/ gelogt.
+ P_LOG_INFO "log_info"
- 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
+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/props/P_LONG b/doc/props/P_LONG
index 04a3659..bad7968 100644
--- a/doc/props/P_LONG
+++ b/doc/props/P_LONG
@@ -1,29 +1,48 @@
+
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.
+NAME
+====
- Diese Property bestimmt die Ansicht des Objektes von aussen. Fuer die
- Innen(lang)ansicht von Raeumen muss man P_INT_LONG benutzen.
+ P_LONG "long"
-BEMERKUNGEN:
- - long() ("untersuche") filtert P_LONG durch process_string()
- -> daher sind Closures moeglich
-BEISPIELE:
+DEFINIERT IN
+============
- SetProp(P_LONG, "Diese Axt ist eine furchtbare Waffe!\n");
+ <thing/description.h>
-SIEHE AUCH:
- Aehnliches: P_SHORT, long()
- Sonstiges: P_INT_LONG, process_string(), break_string()
-----------------------------------------------------------------------------
+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/props/P_LONG_EMPTY b/doc/props/P_LONG_EMPTY
index 1a9cce2..cac74e0 100644
--- a/doc/props/P_LONG_EMPTY
+++ b/doc/props/P_LONG_EMPTY
@@ -1,8 +1,21 @@
-NAME:
- P_LONG_EMPTY "w_longdesc_empty"
-DEFINIERT IN:
- /sys/fishing.h
+P_LONG_EMPTY
+************
-BESCHREIBUNG:
- *** KEINE BESCHREIBUNG VORHANDEN ***
+
+NAME
+====
+
+ P_LONG_EMPTY "w_longdesc_empty"
+
+
+DEFINIERT IN
+============
+
+ /sys/fishing.h
+
+
+BESCHREIBUNG
+============
+
+ *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/props/P_LONG_FULL b/doc/props/P_LONG_FULL
index 3b997f6..7de6081 100644
--- a/doc/props/P_LONG_FULL
+++ b/doc/props/P_LONG_FULL
@@ -1,8 +1,21 @@
-NAME:
- P_LONG_FULL "w_longdesc_full"
-DEFINIERT IN:
- /sys/fishing.h
+P_LONG_FULL
+***********
-BESCHREIBUNG:
- *** KEINE BESCHREIBUNG VORHANDEN ***
+
+NAME
+====
+
+ P_LONG_FULL "w_longdesc_full"
+
+
+DEFINIERT IN
+============
+
+ /sys/fishing.h
+
+
+BESCHREIBUNG
+============
+
+ *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/props/P_MAGIC b/doc/props/P_MAGIC
index b3a0bb7..8994533 100644
--- a/doc/props/P_MAGIC
+++ b/doc/props/P_MAGIC
@@ -1,8 +1,21 @@
-NAME:
- P_MAGIC "magic"
-DEFINIERT IN:
- /sys/properties.h
+P_MAGIC
+*******
-BESCHREIBUNG:
- Dieses Objekt ist magisch.
+
+NAME
+====
+
+ P_MAGIC "magic"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ Dieses Objekt ist magisch.
diff --git a/doc/props/P_MAGIC_RESISTANCE_OFFSET b/doc/props/P_MAGIC_RESISTANCE_OFFSET
index 47ae281..8d270e3 100644
--- a/doc/props/P_MAGIC_RESISTANCE_OFFSET
+++ b/doc/props/P_MAGIC_RESISTANCE_OFFSET
@@ -1,33 +1,52 @@
-NAME:
- P_MAGIC_RESISTANCE_OFFSET "mag_res_offset"
-DEFINIERT IN:
- /sys/new_skills.h
+P_MAGIC_RESISTANCE_OFFSET
+*************************
-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.
+NAME
+====
- P_MAGIC_RESISTANCE_OFFSET und SpellDefend werden von den Spellbooks
- ausgewertet. Der Einfluss ist daher abhaengig vom Spellbook.
+ P_MAGIC_RESISTANCE_OFFSET "mag_res_offset"
-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
+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/props/P_MAILADDR b/doc/props/P_MAILADDR
index e1b849d..32556a7 100644
--- a/doc/props/P_MAILADDR
+++ b/doc/props/P_MAILADDR
@@ -1,8 +1,21 @@
-NAME:
- P_MAILADDR "mailaddr"
-DEFINIERT IN:
- /sys/player/base.h
+P_MAILADDR
+**********
-BESCHREIBUNG:
- EMailadresse des Spielers.
+
+NAME
+====
+
+ P_MAILADDR "mailaddr"
+
+
+DEFINIERT IN
+============
+
+ /sys/player/base.h
+
+
+BESCHREIBUNG
+============
+
+ EMailadresse des Spielers.
diff --git a/doc/props/P_MAP_RESTRICTIONS b/doc/props/P_MAP_RESTRICTIONS
index fd422c0..ee9e620 100644
--- a/doc/props/P_MAP_RESTRICTIONS
+++ b/doc/props/P_MAP_RESTRICTIONS
@@ -1,39 +1,56 @@
-NAME:
- P_MAP_RESTRICTIONS "lib_p_map_restrictions"
-DEFINIERT IN:
- /sys/rooms.h
+P_MAP_RESTRICTIONS
+******************
-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.
+NAME
+====
- 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.
+ P_MAP_RESTRICTIONS "lib_p_map_restrictions"
- Die Verwendung dieser Property sollte der Ausnahmefall sein!
-BEISPIEL:
- (in einem Raum)
- SetProp(P_MAP_RESTRICTIONS, MR_NOUID);
+DEFINIERT IN
+============
- Nun bekommt der Client zwar die Kurzbeschreibung des Raums, die Region
- und die sichtbaren Ausgaenge, aber keine UID mehr uebermittelt.
+ /sys/rooms.h
-SIEHE AUCH:
- gmcp
-----------------------------------------------------------------------------
+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/props/P_MARRIED b/doc/props/P_MARRIED
index 768404e..7cafa6f 100644
--- a/doc/props/P_MARRIED
+++ b/doc/props/P_MARRIED
@@ -1,12 +1,28 @@
-NAME:
- P_MARRIED "married"
-DEFINIERT IN:
- /sys/properties.h
+P_MARRIED
+*********
-BESCHREIBUNG:
- Enthaelt einen String mit der uid des Partners
- (sofern vorhanden)
-SIEHE AUCH:
- scheidung
+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/props/P_MATERIAL b/doc/props/P_MATERIAL
index 5be1bef..4ea4032 100644
--- a/doc/props/P_MATERIAL
+++ b/doc/props/P_MATERIAL
@@ -1,79 +1,99 @@
+
P_MATERIAL
-NAME:
- P_MATERIAL "material"
+**********
-DEFINIERT IN:
- <thing/material.h>
-BESCHREIBUNG:
- Mapping mit prozentualen Anteilen von Materialien, aus denen ein Objekt
- besteht.
+NAME
+====
-BEMERKUNGEN:
- Bei SetProp kann man zu Vereinfachung auch ein einzelnes Material oder
- ein Array aus Materialien angeben. Die Anteile werden dann
- gleichmaessig verteilt.
+ P_MATERIAL "material"
-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])
+DEFINIERT IN
+============
- // 60% Eis, 40% Misc-Holz
- SetProp(P_MATERIAL, ([ MAT_ICE: 60, MAT_MISC_WOOD: 40 ]));
+ <thing/material.h>
- // 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])
+BESCHREIBUNG
+============
- // ein weiser Schmied, der was daraus macht:
- int i;
- string *mat, mname, mgroup;
- mat=m_indices(ob->QueryProp(P_MATERIAL));
- i=sizeof(mat);
+ Mapping mit prozentualen Anteilen von Materialien, aus denen ein Objekt
+ besteht.
- 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);
+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
+SIEHE AUCH
+==========
-7. Mai 2004 Gloinson
\ No newline at end of file
+ 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/props/P_MATERIAL_KNOWLEDGE b/doc/props/P_MATERIAL_KNOWLEDGE
index c954083..0694fef 100644
--- a/doc/props/P_MATERIAL_KNOWLEDGE
+++ b/doc/props/P_MATERIAL_KNOWLEDGE
@@ -1,39 +1,56 @@
+
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})]));
+NAME
+====
-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()
+ P_MATERIAL_KNOWLEDGE "material_knowledge"
-7. Mai 2004 Gloinson
\ No newline at end of file
+
+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/props/P_MAX_ALCOHOL b/doc/props/P_MAX_ALCOHOL
index 10a64c3..541972f 100644
--- a/doc/props/P_MAX_ALCOHOL
+++ b/doc/props/P_MAX_ALCOHOL
@@ -1,21 +1,39 @@
-NAME:
- P_MAX_ALCOHOL "max_alcohol"
-DEFINIERT IN:
- /sys/living/life.h
+P_MAX_ALCOHOL
+*************
-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).
+NAME
+====
-SIEHE AUCH:
- P_ALCOHOL, P_ALCOHOL_DELAY, drink_alcohol,
- P_MAX_FOOD, P_MAX_DRINK
+ 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/props/P_MAX_DRINK b/doc/props/P_MAX_DRINK
index 940eddc..33fdeb8 100644
--- a/doc/props/P_MAX_DRINK
+++ b/doc/props/P_MAX_DRINK
@@ -1,21 +1,39 @@
-NAME:
- P_MAX_DRINK "max_drink"
-DEFINIERT IN:
- /sys/living/life.h
+P_MAX_DRINK
+***********
-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).
+NAME
+====
-SIEHE AUCH:
- P_DRINK, P_DRINK_DELAY, drink_soft,
- P_MAX_FOOD, P_MAX_ALCOHOL
+ 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/props/P_MAX_FOOD b/doc/props/P_MAX_FOOD
index 5f49cfe..fa7f661 100644
--- a/doc/props/P_MAX_FOOD
+++ b/doc/props/P_MAX_FOOD
@@ -1,20 +1,38 @@
-NAME:
- P_MAX_FOOD "max_food"
-DEFINIERT IN:
- /sys/living/life.h
+P_MAX_FOOD
+**********
-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).
+NAME
+====
-SIEHE AUCH:
- P_FOOD, P_FOOD_DELAY, eat_food,
- P_MAX_DRINK, P_MAX_ALCOHOL
+ 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/props/P_MAX_HANDS b/doc/props/P_MAX_HANDS
index 96b1ae8..4c65afa 100644
--- a/doc/props/P_MAX_HANDS
+++ b/doc/props/P_MAX_HANDS
@@ -1,27 +1,45 @@
+
P_MAX_HANDS
-NAME:
- P_MAX_HANDS "max_hands"
+***********
-DEFINIERT IN:
- /sys/living/combat.h
-BESCHREIBUNG:
- Anzahl der Haende, die ein Wesen hat.
+NAME
+====
-BEMERKUNGEN:
- An dieser Propertie sollte bei Spielern nur im Rahmen der
- Gilden 'gespielt' werden.
+ P_MAX_HANDS "max_hands"
- Fuer Magier, die in ihren Npc gerne alle Properties setzen,
- gilt folgendes:
- Setzt diese Propertie NIE auf 0 !
+DEFINIERT IN
+============
- Ohne Haende wird kein Npc irgendeinen Spieler angreifen koennen.
+ /sys/living/combat.h
-SIEHE AUCH:
- P_HANDS, P_HANDS_USED_BY
- P_USED_HANDS, P_FREE_HANDS
- UseHands, FreeHands
+
+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/props/P_MAX_HP b/doc/props/P_MAX_HP
index 13a84c4..fcb3cb0 100644
--- a/doc/props/P_MAX_HP
+++ b/doc/props/P_MAX_HP
@@ -1,14 +1,30 @@
-NAME:
- P_MAX_HP "max_hp"
-DEFINIERT IN:
- /sys/living/life.h
+P_MAX_HP
+********
-BESCHREIBUNG:
- Maximale Anzahl der Lebenspunkte.
-SIEHE AUCH:
- Props: P_HP
- Verwandt: UpdateAttributes()
+NAME
+====
-21.April 2006 Gloinson
\ No newline at end of file
+ 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/props/P_MAX_OBJECTS b/doc/props/P_MAX_OBJECTS
index a76f0d1..68c008f 100644
--- a/doc/props/P_MAX_OBJECTS
+++ b/doc/props/P_MAX_OBJECTS
@@ -1,22 +1,44 @@
-NAME:
- P_MAX_OBJECTS "max_objects"
-DEFINIERT IN:
- /sys/container.h
+P_MAX_OBJECTS
+*************
-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.
+NAME
+====
-BEISPIELE:
- Als Beispiel sollte man sich das Postpaket ansehen und sich an dessen
- Werten orientieren (/p/service/loco/obj/parcel).
+ P_MAX_OBJECTS "max_objects"
-SIEHE AUCH:
- P_MAX_WEIGHT, P_WEIGHT_PERCENT, P_LIGHT_TRANSPARENCY, container
+
+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/props/P_MAX_PASSENGERS b/doc/props/P_MAX_PASSENGERS
index b0bc6a5..32e5f27 100644
--- a/doc/props/P_MAX_PASSENGERS
+++ b/doc/props/P_MAX_PASSENGERS
@@ -1,9 +1,22 @@
-NAME:
- P_MAX_PASSENGERS "maxpass"
-DEFINIERT IN:
- /sys/transport.h
+P_MAX_PASSENGERS
+****************
-BESCHREIBUNG:
- Numerischer Wert fuer die maximale Anzahl von Wesen in dem Transporter.
- 0 bedeutet unbeschaenkte Spielerzahl.
+
+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/props/P_MAX_POISON b/doc/props/P_MAX_POISON
index 35b8e9b..0d39dc4 100644
--- a/doc/props/P_MAX_POISON
+++ b/doc/props/P_MAX_POISON
@@ -1,8 +1,21 @@
-NAME:
- P_MAX_POISON "max_poison"
-DEFINIERT IN:
- /sys/properties.h
+P_MAX_POISON
+************
-BESCHREIBUNG:
- Maximale Vergiftung
+
+NAME
+====
+
+ P_MAX_POISON "max_poison"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ Maximale Vergiftung
diff --git a/doc/props/P_MAX_SP b/doc/props/P_MAX_SP
index 307aaf5..7f7aa43 100644
--- a/doc/props/P_MAX_SP
+++ b/doc/props/P_MAX_SP
@@ -1,14 +1,30 @@
-NAME:
- P_MAX_SP "max_sp"
-DEFINIERT IN:
- /sys/living/life.h
+P_MAX_SP
+********
-BESCHREIBUNG:
- Maximale Anzahl der Magiepunkte.
-SIEHE AUCH:
- Props: P_SP
- Verwandt: UpdateAttributes()
+NAME
+====
-21.April 2006 Gloinson
\ No newline at end of file
+ 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/props/P_MAX_WEIGHT b/doc/props/P_MAX_WEIGHT
index 7e2f16b..abd0942 100644
--- a/doc/props/P_MAX_WEIGHT
+++ b/doc/props/P_MAX_WEIGHT
@@ -1,19 +1,38 @@
-NAME:
- P_MAX_WEIGHT "max_weight"
-DEFINIERT IN:
- /sys/container.h
+P_MAX_WEIGHT
+************
-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.
+NAME
+====
-SIEHE AUCH:
- P_WEIGHT_PERCENT, P_MAX_OBJECTS, P_LIGHT_TRANSPARENCY, container
+ 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/props/P_MESSAGE_BEEP b/doc/props/P_MESSAGE_BEEP
index 9e40fa5..6ecf718 100644
--- a/doc/props/P_MESSAGE_BEEP
+++ b/doc/props/P_MESSAGE_BEEP
@@ -1,19 +1,38 @@
-NAME:
- P_MESSAGE_BEEP "message_beep"
-DEFINIERT IN:
- /sys/player/comm.h
+P_MESSAGE_BEEP
+**************
-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
+NAME
+====
-LETZTE AENDERUNG:
+ 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/props/P_MESSAGE_PREPEND b/doc/props/P_MESSAGE_PREPEND
index ee44dda..be54d65 100644
--- a/doc/props/P_MESSAGE_PREPEND
+++ b/doc/props/P_MESSAGE_PREPEND
@@ -1,18 +1,37 @@
-NAME:
- P_MESSAGE_PREPEND "message_prepend"
-DEFINIERT IN:
- /sys/player/comm.h
+P_MESSAGE_PREPEND
+*****************
-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
+NAME
+====
-LETZTE AENDERUNG:
+ 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/props/P_MIN_STOCK b/doc/props/P_MIN_STOCK
index d896fb3..3be8d4e 100644
--- a/doc/props/P_MIN_STOCK
+++ b/doc/props/P_MIN_STOCK
@@ -1,37 +1,55 @@
-NAME:
- P_MIN_STOCK "min_stock"
-DEFINIERT IN:
- /sys/bank.h
+P_MIN_STOCK
+***********
-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.
+NAME
+====
-SIEHE AUCH:
- P_STORE_CONSUME, SetStorageRoom(), /std/store.c, /std/shop.c
- AddItem(), RemoveItem(), AddFixedObject(), RemoveFixedObject()
+ P_MIN_STOCK "min_stock"
-----------------------------------------------------------------------------
-Last modified: 19-Jun-2015, Arathorn
+
+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/props/P_MMSGIN b/doc/props/P_MMSGIN
index cd8e84e..98d37f3 100644
--- a/doc/props/P_MMSGIN
+++ b/doc/props/P_MMSGIN
@@ -1,9 +1,22 @@
-NAME:
- P_MMSGIN "mmsgin"
-DEFINIERT IN:
- /sys/player/moving.h
+P_MMSGIN
+********
-BESCHREIBUNG:
- String mit der Meldung, die beim Verlassen eines Raumes mit M_TPORT
- an die uebrigen Anwesenden ausgegeben wird.
+
+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/props/P_MMSGOUT b/doc/props/P_MMSGOUT
index defd09f..6035ba8 100644
--- a/doc/props/P_MMSGOUT
+++ b/doc/props/P_MMSGOUT
@@ -1,9 +1,22 @@
-NAME:
- P_MMSGOUT "mmsgout"
-DEFINIERT IN:
- /sys/player/moving.h
+P_MMSGOUT
+*********
-BESCHREIBUNG:
- String mit der Meldung, die beim Betreten eines Raumes mit M_TPORT
- an die uebrigen Anwesenden ausgegeben wird.
+
+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/props/P_MSGIN b/doc/props/P_MSGIN
index cf14a91..f5d90f8 100644
--- a/doc/props/P_MSGIN
+++ b/doc/props/P_MSGIN
@@ -1,9 +1,22 @@
-NAME:
- P_MSGIN "msgin"
-DEFINIERT IN:
- /sys/player/moving.h
+P_MSGIN
+*******
-BESCHREIBUNG:
- String mit der Meldung, die beim Betreten eines Raumes mit M_GO
- an die uebrigen Anwesenden ausgegeben wird.
+
+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/props/P_MSGOUT b/doc/props/P_MSGOUT
index 0587afb..95a8545 100644
--- a/doc/props/P_MSGOUT
+++ b/doc/props/P_MSGOUT
@@ -1,9 +1,22 @@
-NAME:
- P_MSGOUT "msgout"
-DEFINIERT IN:
- /sys/player/moving.h
+P_MSGOUT
+********
-BESCHREIBUNG:
- String mit der Meldung, die beim Verlassen eines Raumes mit M_GO
- an die uebrigen Anwesenden ausgegeben wird.
+
+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/props/P_MSG_PROB b/doc/props/P_MSG_PROB
index d520067..b4465df 100644
--- a/doc/props/P_MSG_PROB
+++ b/doc/props/P_MSG_PROB
@@ -1,19 +1,35 @@
-NAME:
- P_MSG_PROB "msg_prob"
-DEFINIERT IN:
- /sys/room/description.h
+P_MSG_PROB
+**********
-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()
+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/props/P_MUD_NEWBIE b/doc/props/P_MUD_NEWBIE
index bebb77f..71801eb 100644
--- a/doc/props/P_MUD_NEWBIE
+++ b/doc/props/P_MUD_NEWBIE
@@ -1,17 +1,31 @@
-NAME:
- P_MUD_NEWBIE "_lib_mud_newbie"
-DEFINIERT IN:
- /sys/player/base.h
+P_MUD_NEWBIE
+************
-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.
+NAME
+====
-SIEHE AUCH:
+ 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/props/P_MURDER_MSG b/doc/props/P_MURDER_MSG
index 63d594c..c565cfa 100644
--- a/doc/props/P_MURDER_MSG
+++ b/doc/props/P_MURDER_MSG
@@ -1,63 +1,83 @@
+
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)];
- }
+NAME
+====
- SetProp(P_MURDER_MSG, #'moerder_meldung);
+ P_MURDER_MSG "murder_msg"
-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.
+DEFINIERT IN
+============
-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
+ /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/props/P_M_ATTR_MOD b/doc/props/P_M_ATTR_MOD
index 8a79717..d279484 100644
--- a/doc/props/P_M_ATTR_MOD
+++ b/doc/props/P_M_ATTR_MOD
@@ -1,42 +1,64 @@
-NAME:
- P_M_ATTR_MOD "magic_attributes_modifier"
-DEFINIERT IN:
- /sys/living/attributes.h
+P_M_ATTR_MOD
+************
-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.
+NAME
+====
- Fuer Krankheiten etc. oder Objekte, deren *Besitz* allein schon die
- Attribute veraendern sollen, verwendet man besser P_X_ATTR_MOD.
+ P_M_ATTR_MOD "magic_attributes_modifier"
- 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.
+DEFINIERT IN
+============
-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]) );
+ /sys/living/attributes.h
-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
+
+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/props/P_M_HEALTH_MOD b/doc/props/P_M_HEALTH_MOD
index a4c89e6..cdc3fd4 100644
--- a/doc/props/P_M_HEALTH_MOD
+++ b/doc/props/P_M_HEALTH_MOD
@@ -1,40 +1,64 @@
-NAME:
- P_M_HEALTH_MOD "magic_health_modifier"
-DEFINIERT IN:
- /sys/living/attributes.h
+P_M_HEALTH_MOD
+**************
-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.
+NAME
+====
- Fuer Krankheiten etc. verwendet man besser die Property P_X_HEALTH_MOD.
+ P_M_HEALTH_MOD "magic_health_modifier"
- 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.
+DEFINIERT IN
+============
-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.
+ /sys/living/attributes.h
-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
+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/props/P_NAME b/doc/props/P_NAME
index f609cea..1fdc261 100644
--- a/doc/props/P_NAME
+++ b/doc/props/P_NAME
@@ -1,65 +1,84 @@
+
P_NAME
+******
-NAME:
- P_NAME "name"
-DEFINIERT IN:
- <thing/description.h>
+NAME
+====
-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.
+ P_NAME "name"
- 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.
+DEFINIERT IN
+============
- Setzt man P_NAME eines Unit-Objekts auf einen einfachen String, so wird
- dieser als Name sowohl im Singular als auch im Plural verwendet.
+ <thing/description.h>
- 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.
+BESCHREIBUNG
+============
-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
+ 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.
- SetProp(P_NAME, ({ "alter Hut", "alten Huts",
- "alten Hut", "alten Hut" }) );
+ Die Funktion name() behandelt recht viele Sonderfaelle; man sollte den
+ Namen also erst einmal in der Form eines einzelnen Strings pruefen.
- besser
+ Eine Sonderrolle nehmen Unit-Objekte ein: Hier kann man einen Namen
+ fuer den Singular und einen Namen fuer den Plural vergeben.
- SetProp(P_NAME, "Hut");
- SetProp(P_NAME_ADJ, "alt");
+ Setzt man P_NAME eines Unit-Objekts auf einen einfachen String, so wird
+ dieser als Name sowohl im Singular als auch im Plural verwendet.
- Bei Lebewesen wird lower_case(P_NAME) (bei Arrays das erste Element
- daraus) automatisch als LivingName gesetzt.
+ Uebergibt man ein Array von Strings, so wird der erste Eintrag fuer den
+ Singular und der zweite Eintrag fuer den Plural benutzt.
-BEISPIELE:
- Ein regelmaessig deklinierbarer Name:
+ Bei Unit-Objekten ist es nicht moeglich, auch noch zwischen den
+ verschiedenen Faellen zu unterscheiden.
- SetProp(P_NAME, "Arkshat");
- Hier ein Beispiel fuer einen unregelmaessig deklinierbaren Namen:
+BEMERKUNGEN
+===========
- SetProp(P_NAME, ({ "Drache", "Drachen", "Drachen", "Drachen" }));
+ 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
- Und schliesslich der Name eines allseits bekannten Unit-Objektes:
+ SetProp(P_NAME, ({ "alter Hut", "alten Huts",
+ "alten Hut", "alten Hut" }) );
- SetProp(P_NAME, ({ "Muenze", "Muenzen" }));
+ besser
-SIEHE AUCH:
- /std/thing/description.c, name(), P_NAME_ADJ, set_living_name(),
- find_living(), find_livings()
+ SetProp(P_NAME, "Hut");
+ SetProp(P_NAME_ADJ, "alt");
-----------------------------------------------------------------------------
-Last modified: 19. Okt. 2015, Arathorn.
+ 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/props/P_NAME_ADJ b/doc/props/P_NAME_ADJ
index 2bf15e6..c4cc4a4 100644
--- a/doc/props/P_NAME_ADJ
+++ b/doc/props/P_NAME_ADJ
@@ -1,55 +1,72 @@
+
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
+====
- name(WESSEN,1) => "des alten, gammeligen Huts"
+ P_NAME_ADJ "name_adj"
- // 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"
+DEFINIERT IN
+============
- // 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"
+ <thing/description.h>
-SIEHE AUCH:
- /std/thing/description.c, name(), P_NAME, DeclAdj()
+
+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/props/P_NEEDED_QP b/doc/props/P_NEEDED_QP
index e38f9eb..2df4c78 100644
--- a/doc/props/P_NEEDED_QP
+++ b/doc/props/P_NEEDED_QP
@@ -1,15 +1,31 @@
-NAME:
- P_NEEDED_QP "needed_qp"
-DEFINIERT IN:
- /sys/player/base.h
+P_NEEDED_QP
+***********
-BESCHREIBUNG:
- APs, die man fuer den Seherstatus braucht
- Diese Property ist mittlerweile obsolet. Die
- aktuell geltenden Seher-Anforderungen stehen in
- /secure/lepmaster.h
+NAME
+====
-LETZTE AENDERUNG:
- 2006-09-30, Zook.
\ No newline at end of file
+ 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/props/P_NETDEAD_ENV b/doc/props/P_NETDEAD_ENV
index b2d6317..2e46f5d 100644
--- a/doc/props/P_NETDEAD_ENV
+++ b/doc/props/P_NETDEAD_ENV
@@ -1,24 +1,43 @@
-NAME:
- P_NETDEAD_ENV "netdead_env"
-DEFINIERT IN:
- /sys/player/base.h
+P_NETDEAD_ENV
+*************
-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).
+NAME
+====
- Bei nicht netztoten Spielern wird 0 zurueckgegeben.
+ P_NETDEAD_ENV "netdead_env"
-BEMERKUNGEN:
- Diese Property ist read-only.
-SIEHE AUCH:
- P_NETDEAD_INFO
+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/props/P_NETDEAD_INFO b/doc/props/P_NETDEAD_INFO
index 83c36fd..fe96ac6 100644
--- a/doc/props/P_NETDEAD_INFO
+++ b/doc/props/P_NETDEAD_INFO
@@ -1,91 +1,120 @@
-NAME:
- P_NETDEAD_INFO "netdead_info"
-DEFINIERT IN:
- /sys/player.h
+P_NETDEAD_INFO
+**************
-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.
+NAME
+====
-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.
+ P_NETDEAD_INFO "netdead_info"
-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";
+DEFINIERT IN
+============
- void create() {
- ::create();
+ /sys/player.h
- 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);
- }
+BESCHREIBUNG
+============
- // 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";
+ 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/props/P_NEVERDROP b/doc/props/P_NEVERDROP
index 80364ce..d0cdf41 100644
--- a/doc/props/P_NEVERDROP
+++ b/doc/props/P_NEVERDROP
@@ -1,29 +1,50 @@
-NAME:
- P_NEVERDROP "neverdrop"
-DEFINIERT IN:
- /sys/thing/moving.h
+P_NEVERDROP
+***********
-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.
+NAME
+====
-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.
+ P_NEVERDROP "neverdrop"
-SIEHE AUCH:
- P_NODROP, P_NOGET, P_NOCORPSE, P_AUTOLOADOBJ, /std/living/life.c
-----------------------------------------------------------------------------
+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/props/P_NEVER_CLEAN b/doc/props/P_NEVER_CLEAN
index 5a84820..fc568ff 100644
--- a/doc/props/P_NEVER_CLEAN
+++ b/doc/props/P_NEVER_CLEAN
@@ -1,35 +1,53 @@
-NAME:
- P_NEVER_CLEAN " never clean "
-DEFINIERT IN:
- /sys/rooms.h
+P_NEVER_CLEAN
+*************
-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.
+NAME
+====
-SIEHE AUCH:
- /std/room.c
+ 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/props/P_NEWSKILLS b/doc/props/P_NEWSKILLS
index 66ba1ff..7cb61c7 100644
--- a/doc/props/P_NEWSKILLS
+++ b/doc/props/P_NEWSKILLS
@@ -1,20 +1,38 @@
-NAME:
- P_NEWSKILLS "newskills"
-DEFINIERT IN:
- /sys/new_skills.h
+P_NEWSKILLS
+***********
-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.
+NAME
+====
-SIEHE AUCH:
- ModifySkill(), LearnSkill(), UseSkill(), /std/living/skills.c,
- P_GUILD_SKILLS, P_SB_SPELLS
+ 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/props/P_NEXT_DEATH_SEQUENCE b/doc/props/P_NEXT_DEATH_SEQUENCE
index 4ae7e7a..6992a32 100644
--- a/doc/props/P_NEXT_DEATH_SEQUENCE
+++ b/doc/props/P_NEXT_DEATH_SEQUENCE
@@ -1,48 +1,68 @@
+
P_NEXT_DEATH_SEQUENCE
+*********************
-NAME:
- P_NEXT_DEATH_SEQUENCE "p_lib_next_death_sequence"
-DEFINIERT IN:
- /sys/living/combat.h
+NAME
+====
-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.
+ P_NEXT_DEATH_SEQUENCE "p_lib_next_death_sequence"
- 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.
+DEFINIERT IN
+============
-BEISPIELE:
- // Pfad zu einer eigenen DSQ
- SetProp(P_NEXT_DEATH_SEQUENCE, ".../passende_dsq.txt");
+ /sys/living/combat.h
- // 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"]));
+BESCHREIBUNG
+============
-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
+ 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.
-10. Nov 2011 Gloinson
\ No newline at end of file
+ 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/props/P_NEXT_DISABLE_ATTACK b/doc/props/P_NEXT_DISABLE_ATTACK
index 7019ac6..6a9eea3 100644
--- a/doc/props/P_NEXT_DISABLE_ATTACK
+++ b/doc/props/P_NEXT_DISABLE_ATTACK
@@ -1,31 +1,52 @@
-PROPERTY
- P_NEXT_DISABLE_ATTACK "next_diable_attack"
-DEFINIERT IN
- combat.h
+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 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.
- Diese Set-Methode verhindert das Setzen von P_NEXT_DISABLE_ATTACK mittels
- eines SetProp-Aufrufes.
+ 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:
-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
+
+ 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/props/P_NOBUY b/doc/props/P_NOBUY
index 561bbba..27f6c70 100644
--- a/doc/props/P_NOBUY
+++ b/doc/props/P_NOBUY
@@ -1,10 +1,23 @@
-NAME:
- P_NOBUY "nobuy"
-DEFINIERT IN:
- /sys/properties.h
+P_NOBUY
+*******
-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.
+
+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/props/P_NOCORPSE b/doc/props/P_NOCORPSE
index 799391a..15d5de2 100644
--- a/doc/props/P_NOCORPSE
+++ b/doc/props/P_NOCORPSE
@@ -1,30 +1,51 @@
-NAME:
- P_NOCORPSE "nocorpse"
-DEFINIERT IN:
- /sys/properties.h
+P_NOCORPSE
+**********
-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.
+NAME
+====
-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.
+ P_NOCORPSE "nocorpse"
-SIEHE AUCH:
- P_CORPSE, P_ZAP_MSG, P_DIE_MSG, P_MURDER_MSG, P_KILL_MSG,
- P_NEVERDROP, /std/corpse.c
-----------------------------------------------------------------------------
+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/props/P_NODRINK_MSG b/doc/props/P_NODRINK_MSG
index 3f847c7..a3407c7 100644
--- a/doc/props/P_NODRINK_MSG
+++ b/doc/props/P_NODRINK_MSG
@@ -1,25 +1,46 @@
-NAME:
- P_NODRINK_MSG "std_food_nodrink_msg"
-DEFINIERT IN:
- <sys/food.h>
+P_NODRINK_MSG
+*************
-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
+NAME
+====
-------------------------------------------------------------------------------
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
\ No newline at end of file
+ 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/props/P_NODROP b/doc/props/P_NODROP
index 37eb5b5..786cdea 100644
--- a/doc/props/P_NODROP
+++ b/doc/props/P_NODROP
@@ -1,39 +1,60 @@
-NAME:
- P_NODROP "nodrop"
-DEFINIERT IN:
- /sys/thing/moving.h
+P_NODROP
+********
-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.
+NAME
+====
-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");
+ P_NODROP "nodrop"
-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
-----------------------------------------------------------------------------
+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/props/P_NOFOOD_MSG b/doc/props/P_NOFOOD_MSG
index c367b7c..d195c5e 100644
--- a/doc/props/P_NOFOOD_MSG
+++ b/doc/props/P_NOFOOD_MSG
@@ -1,25 +1,46 @@
-NAME:
- P_NOFOOD_MSG "std_food_nofood_msg"
-DEFINIERT IN:
- <sys/food.h>
+P_NOFOOD_MSG
+************
-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
+NAME
+====
-------------------------------------------------------------------------------
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
\ No newline at end of file
+ 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/props/P_NOGET b/doc/props/P_NOGET
index af3ed1d..17a6248 100644
--- a/doc/props/P_NOGET
+++ b/doc/props/P_NOGET
@@ -1,31 +1,49 @@
-NAME:
- P_NOGET "noget"
-DEFINIERT IN:
- /sys/thing/moving.h
+P_NOGET
+*******
-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.
+NAME
+====
-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
+ 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/props/P_NOINSERT_MSG b/doc/props/P_NOINSERT_MSG
index a79994e..de7d8e8 100644
--- a/doc/props/P_NOINSERT_MSG
+++ b/doc/props/P_NOINSERT_MSG
@@ -1,46 +1,65 @@
-NAME:
- P_NOINSERT_MSG "noinsert_msg"
-DEFINIERT IN:
- /sys/thing/moving.h
+P_NOINSERT_MSG
+**************
-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!
+NAME
+====
- 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 ...
+ P_NOINSERT_MSG "noinsert_msg"
-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
+
+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/props/P_NOLEAVE_MSG b/doc/props/P_NOLEAVE_MSG
index 0a226dd..d2cd164 100644
--- a/doc/props/P_NOLEAVE_MSG
+++ b/doc/props/P_NOLEAVE_MSG
@@ -1,33 +1,52 @@
-NAME:
- P_NOLEAVE_MSG "noleave_msg"
-DEFINIERT IN:
- /sys/thing/moving.h
+P_NOLEAVE_MSG
+*************
-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!");
+NAME
+====
-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
+ 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/props/P_NOMAGIC b/doc/props/P_NOMAGIC
index bdee7f7..42e51d1 100644
--- a/doc/props/P_NOMAGIC
+++ b/doc/props/P_NOMAGIC
@@ -1,21 +1,42 @@
-NAME:
- P_NOMAGIC "nomagic"
-DEFINIERT IN:
- /sys/properties.h
+P_NOMAGIC
+*********
-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)
+NAME
+====
-SIEHE AUCH:
- Aehnlich: P_MAGIC_RESISTANCE_OFFSET, SpellDefend
+ 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/props/P_NOSELL b/doc/props/P_NOSELL
index 48b0ddb..6141be3 100644
--- a/doc/props/P_NOSELL
+++ b/doc/props/P_NOSELL
@@ -1,33 +1,50 @@
-NAME:
- P_NOSELL "nosell"
-DEFINIERT IN:
- /sys/properties.h
+P_NOSELL
+********
-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.
+NAME
+====
-BEISPIEL:
- SetProp(P_NOSELL,"Den Schrott behaeltst Du lieber selber.");
+ P_NOSELL "nosell"
- ==> Apu sagt: Den Schrott behaeltst Du lieber selber.
- ==> Der Haendler sagt: Den Schrott behaeltst Du lieber selber.
- SetProp(P_NOSELL,1);
+DEFINIERT IN
+============
- ==> Apu sagt: Du kannst <name> nicht verkaufen!
- ==> Der Haendler sagt: Du kannst <name> nicht verkaufen!
+ /sys/properties.h
-SIEHE AUCH:
- P_NOBUY, P_NODROP, P_KEEPER
-----------------------------------------------------------------------------
+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/props/P_NO_ASCII_ART b/doc/props/P_NO_ASCII_ART
index 9b40cde..3a143a4 100644
--- a/doc/props/P_NO_ASCII_ART
+++ b/doc/props/P_NO_ASCII_ART
@@ -1,20 +1,35 @@
-NAME:
- P_NO_ASCII_ART "no_ascii_art"
+
+P_NO_ASCII_ART
+**************
-DEFINIERT IN:
- /sys/player/base.h
+NAME
+====
-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.
+ P_NO_ASCII_ART "no_ascii_art"
- 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.
+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/props/P_NO_ATTACK b/doc/props/P_NO_ATTACK
index 0f39180..9ca4c95 100644
--- a/doc/props/P_NO_ATTACK
+++ b/doc/props/P_NO_ATTACK
@@ -1,82 +1,99 @@
+
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!
+NAME
+====
+
+ P_NO_ATTACK "no_attack"
-LETZTE AENDERUNG:
+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/props/P_NO_BAD b/doc/props/P_NO_BAD
index 60df1e7..ae2adf2 100644
--- a/doc/props/P_NO_BAD
+++ b/doc/props/P_NO_BAD
@@ -1,23 +1,43 @@
-NAME:
- P_NO_BAD "std_food_no_bad"
-DEFINIERT IN:
- <sys/food.h>
+P_NO_BAD
+********
-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
+NAME
+====
-------------------------------------------------------------------------------
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
\ No newline at end of file
+ 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/props/P_NO_GLOBAL_ATTACK b/doc/props/P_NO_GLOBAL_ATTACK
index 01df4e9..962186c 100644
--- a/doc/props/P_NO_GLOBAL_ATTACK
+++ b/doc/props/P_NO_GLOBAL_ATTACK
@@ -1,20 +1,33 @@
+
P_NO_GLOBAL_ATTACK
+******************
-NAME:
- P_NO_GLOBAL_ATTACK "no_global_attack"
-DEFINIERT IN:
- <combat.h>
+NAME
+====
-BESCHREIBUNG:
- Setzt man diese Property in einem NPC auf einen Wert ungleich 0, so
- wird der NPC bei einem "toete alle" nicht angegriffen.
+ P_NO_GLOBAL_ATTACK "no_global_attack"
- 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
+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/props/P_NO_PARA_TRANS b/doc/props/P_NO_PARA_TRANS
index 578c245..677f9c8 100644
--- a/doc/props/P_NO_PARA_TRANS
+++ b/doc/props/P_NO_PARA_TRANS
@@ -1,15 +1,30 @@
-NAME:
- P_NO_PARA_TRANS "no_para_trans"
-DEFINIERT IN:
- /sys/properties.h
+P_NO_PARA_TRANS
+***************
-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
+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/props/P_NO_PLAYERS b/doc/props/P_NO_PLAYERS
index 062b915..3cc88c1 100644
--- a/doc/props/P_NO_PLAYERS
+++ b/doc/props/P_NO_PLAYERS
@@ -1,37 +1,56 @@
-NAME:
- P_NO_PLAYERS "no_players"
-DEFINIERT IN:
- /sys/rooms.h
+P_NO_PLAYERS
+************
-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.
+NAME
+====
- 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!
+ P_NO_PLAYERS "no_players"
- (*) 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.
+DEFINIERT IN
+============
- 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. ;-)
+ /sys/rooms.h
-SIEHE AUCH:
- P_PARA, move
+
+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/props/P_NO_REGENERATION b/doc/props/P_NO_REGENERATION
index b8dea8c..cc672e3 100644
--- a/doc/props/P_NO_REGENERATION
+++ b/doc/props/P_NO_REGENERATION
@@ -1,34 +1,52 @@
+
P_NO_REGENERATION
+*****************
-NAME:
- P_NO_REGENERATION "no_regeneration"
-DEFINIERT IN:
- <living/life.h> und <health.h>
+NAME
+====
-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 ;).
+ P_NO_REGENERATION "no_regeneration"
-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
+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/props/P_NO_SCORE b/doc/props/P_NO_SCORE
index 6c4a2d2..49cfee5 100644
--- a/doc/props/P_NO_SCORE
+++ b/doc/props/P_NO_SCORE
@@ -1,51 +1,73 @@
-NAME:
- P_NO_SCORE "no_score"
-DEFINIERT IN:
- /secure/scoremaster.h
+P_NO_SCORE
+**********
-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.
+NAME
+====
- Mit der gesetzten Property P_NO_SCORE im Opfer erreicht man nun,
- dass diese Gutschrift fuer den/die Angreifer unterbunden wird.
+ P_NO_SCORE "no_score"
-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);
- }
+DEFINIERT IN
+============
- 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).
+ /secure/scoremaster.h
-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
+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/props/P_NO_STD_DRINK b/doc/props/P_NO_STD_DRINK
index a91e92d..f8c2f33 100644
--- a/doc/props/P_NO_STD_DRINK
+++ b/doc/props/P_NO_STD_DRINK
@@ -1,19 +1,37 @@
-NAME:
- P_NO_STD_DRINK "no_std_drink"
-DEFINIERT IN:
- /sys/pub.h
+P_NO_STD_DRINK
+**************
-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.
+NAME
+====
-SIEHE AUCH:
- /std/room/pub.c
+ 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/props/P_NO_TPORT b/doc/props/P_NO_TPORT
index 40350e5..1c6de77 100644
--- a/doc/props/P_NO_TPORT
+++ b/doc/props/P_NO_TPORT
@@ -1,15 +1,30 @@
-NAME:
- P_NO_TPORT "tport"
-DEFINIERT IN:
- /sys/properties.h
+P_NO_TPORT
+**********
-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
+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/props/P_NO_TRAVELING b/doc/props/P_NO_TRAVELING
index 61425bc..cd1073a 100644
--- a/doc/props/P_NO_TRAVELING
+++ b/doc/props/P_NO_TRAVELING
@@ -1,25 +1,48 @@
-NAME:
- P_NO_TRAVELING "no_traveling"
-DEFINIERT IN:
- /sys/transport.h
+P_NO_TRAVELING
+**************
-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.
+NAME
+====
- 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.
+ P_NO_TRAVELING "no_traveling"
-SIEHE AUCH:
- reise
-LETZTER AENDERUNG:
- Don, 24.01.2002, 10:15:07h von Tilly
-
\ No newline at end of file
+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/props/P_NO_XP b/doc/props/P_NO_XP
index bb09b2a..b16c4ab 100644
--- a/doc/props/P_NO_XP
+++ b/doc/props/P_NO_XP
@@ -1,43 +1,65 @@
-NAME:
- P_NO_XP "no_xp"
-DEFINIERT IN:
- /sys/living/life.h
+P_NO_XP
+*******
-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.
+NAME
+====
-BEISPIEL:
- Folgendermassen unterbindet man die Vergabe von Erfahrungspunkte
- fuer den Angriff eines NPC's:
+ P_NO_XP "no_xp"
- 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!
+DEFINIERT IN
+============
- Auch fuer das kurzzeitige Unterbinden der Vergabe von
- Erfahrungspunkten ist diese Property sinnvoller, als P_XP im NPC
- auf 0 zu setzen.
+ /sys/living/life.h
-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()
+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/props/P_NPC b/doc/props/P_NPC
index 69d1270..60651d8 100644
--- a/doc/props/P_NPC
+++ b/doc/props/P_NPC
@@ -1,8 +1,21 @@
-NAME:
- P_NPC "is_npc"
-DEFINIERT IN:
- /sys/properties.h
+P_NPC
+*****
-BESCHREIBUNG:
- Gesetzt bei Monstern.
+
+NAME
+====
+
+ P_NPC "is_npc"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ Gesetzt bei Monstern.
diff --git a/doc/props/P_NPC_FASTHEAL b/doc/props/P_NPC_FASTHEAL
index 3f588b9..3c358ef 100644
--- a/doc/props/P_NPC_FASTHEAL
+++ b/doc/props/P_NPC_FASTHEAL
@@ -1,21 +1,39 @@
-NAME:
- P_NPC_FASTHEAL "npc_fastheal"
-DEFINIERT IN:
- /sys/pub.h
+P_NPC_FASTHEAL
+**************
-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.
+NAME
+====
-SIEHE AUCH:
- /std/room/pub.c
+ 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/props/P_NR_HANDS b/doc/props/P_NR_HANDS
index b0827a9..a3bf299 100644
--- a/doc/props/P_NR_HANDS
+++ b/doc/props/P_NR_HANDS
@@ -1,31 +1,45 @@
+
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!
+NAME
+====
- 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.
+ P_NR_HANDS "nr_hands"
- Defaultmaessig sind alle Waffen Zweihaender.
- Diese Property kann auch bei Zaubern benutzt werden, bei denen man eine
- oder mehrere Haende frei haben muss.
+DEFINIERT IN
+============
-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
+ <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/props/P_ORAKEL b/doc/props/P_ORAKEL
index cf383da..773a80d 100644
--- a/doc/props/P_ORAKEL
+++ b/doc/props/P_ORAKEL
@@ -1,9 +1,22 @@
-NAME:
- P_ORAKEL "orakel"
-DEFINIERT IN:
- /sys/properties.h
+P_ORAKEL
+********
-BESCHREIBUNG:
- Wenn diese Property gesetzt ist, kann der Wanderer in diesen
- Raum hinein.
+
+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/props/P_ORIG_FILE_NAME b/doc/props/P_ORIG_FILE_NAME
index 2064360..53243c2 100644
--- a/doc/props/P_ORIG_FILE_NAME
+++ b/doc/props/P_ORIG_FILE_NAME
@@ -1,8 +1,21 @@
-NAME:
- P_ORIG_FILE_NAME "original_object_name"
-DEFINIERT IN:
- /sys/properties.h
+P_ORIG_FILE_NAME
+****************
-BESCHREIBUNG:
- In einer Leiche der Filename des Gestorbenen.
+
+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/props/P_ORIG_NAME b/doc/props/P_ORIG_NAME
index 96a5d73..e44a06d 100644
--- a/doc/props/P_ORIG_NAME
+++ b/doc/props/P_ORIG_NAME
@@ -1,8 +1,21 @@
-NAME:
- P_ORIG_NAME "original_name"
-DEFINIERT IN:
- /sys/properties.h
+P_ORIG_NAME
+***********
-BESCHREIBUNG:
- In einer Leiche der Name des Gestorbenen. (name(RAW))
+
+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/props/P_PARA b/doc/props/P_PARA
index 87cc92b..0a7f416 100644
--- a/doc/props/P_PARA
+++ b/doc/props/P_PARA
@@ -1,54 +1,73 @@
-NAME:
- P_PARA "para"
-DEFINIERT IN:
- /sys/properties.h
+P_PARA
+******
-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.
+NAME
+====
- 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.
+ P_PARA "para"
- 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.
+DEFINIERT IN
+============
- Raeume mit Endungen '^n.c', bei denen 'n' keine positive ganze Zahl ist,
- werden nicht beachtet.
+ /sys/properties.h
- 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).
+BESCHREIBUNG
+============
- 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.
+ Nummer der Parallelwelt, in der sich ein Spieler befindet.
-SIEHE AUCH:
- P_NO_PLAYERS, move, pararaeume
-
+ 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/props/P_PARRY b/doc/props/P_PARRY
index 03550df..40ddecd 100644
--- a/doc/props/P_PARRY
+++ b/doc/props/P_PARRY
@@ -1,31 +1,47 @@
+
P_PARRY
+*******
-NAME:
- P_PARRY "parry"
-DEFINIERT IN:
- <combat.h>
+NAME
+====
-BESCHREIBUNG:
- Diese Property legt fest, inwiefern eine Waffe als Parierwaffe
- genutzt werden kann. Moegliche Werte:
+ P_PARRY "parry"
- PARRY_NOT Eine reine Angriffswaffe ohne Parierfunktion.
- PARRY_TOO Eine kombinierte Angriffs- und Parierwaffe.
+DEFINIERT IN
+============
- PARRY_ONLY Eine reine Parierwaffe. Diese kann zusaetzlich
- zu einer normalen Waffe gezueckt werden.
+ <combat.h>
- 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.
+BESCHREIBUNG
+============
-SIEHE AUCH:
- /std/weapon/combat.c
+ 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/props/P_PARRY_WEAPON b/doc/props/P_PARRY_WEAPON
index c873bfb..9ee60aa 100644
--- a/doc/props/P_PARRY_WEAPON
+++ b/doc/props/P_PARRY_WEAPON
@@ -1,17 +1,30 @@
+
P_PARRY_WEAPON
+**************
-NAME:
- P_PARRY_WEAPON "parry_weapon"
-DEFINIERT IN:
- <combat.h>
+NAME
+====
-BESCHREIBUNG:
- Diese Property gibt an, welche Parierwaffe ein Spieler derzeit
- gezueckt hat.
+ P_PARRY_WEAPON "parry_weapon"
-SIEHE AUCH:
- /std/weapon/combat.c, /std/living/combat.c
-----------------------------------------------------------------------------
+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/props/P_PEACE_HISTORY b/doc/props/P_PEACE_HISTORY
index f3cb2d2..eab38d5 100644
--- a/doc/props/P_PEACE_HISTORY
+++ b/doc/props/P_PEACE_HISTORY
@@ -1,42 +1,62 @@
+
P_PEACE_HISTORY
+***************
-NAME:
- P_PEACE_HISTORY "_peace_history"
-DEFINIERT IN:
- /sys/living/combat.h
+NAME
+====
-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.
+ P_PEACE_HISTORY "_peace_history"
-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)
+DEFINIERT IN
+============
-SIEHE AUCH:
- P_PEACE_ACCEPT
- QueryPacify()
- /std/living/combat.c
+ /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/props/P_PERM_STRING b/doc/props/P_PERM_STRING
index d7904b7..373c516 100644
--- a/doc/props/P_PERM_STRING
+++ b/doc/props/P_PERM_STRING
@@ -1,11 +1,24 @@
-NAME:
- P_PERM_STRING "perm_string"
-DEFINIERT IN:
- /sys/player/comm.h
+P_PERM_STRING
+*************
-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.
+
+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/props/P_PICK_MSG b/doc/props/P_PICK_MSG
index f77d508..76b2760 100644
--- a/doc/props/P_PICK_MSG
+++ b/doc/props/P_PICK_MSG
@@ -1,60 +1,78 @@
+
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.
+NAME
+====
- Folgende Werte sind moeglich:
+ P_PICK_MSG "pick_message"
- o 0
- Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
- o NO_PNG_MSG == -1
- Es wird keinerlei Meldung ausgegeben
+DEFINIERT IN
+============
- o Ein Array aus Strings
- Der erste String wird an den Spieler ausgegeben, der zweite
- (optionale) an den Raum.
+ /sys/living/put_and_get.h
- 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.
+BESCHREIBUNG
+============
-BEISPIEL:
- void create() {
- ...
- SetProp( P_SHORT, "Etwas Sand" );
- SetProp( P_LONG, break_string(
- "Ein wenig magischer Sand. Sehr feinkruemelig.",78 ));
+ Mit P_PICK_MSG kann man die Meldung, die man beim Aufnehmen eines
+ Objektes bekommt, modifizieren.
- SetProp( P_NAME, "Sand" );
- AddId( ({"sand"}) );
- SetProp( P_GENDER, MALE );
+ Folgende Werte sind moeglich:
- SetProp( P_PICK_MSG, ({
- "Du schaufelst @WEN2 in deine Hand.",
- "@WER1 schaufelt @WEN2 in eine Hand."}));
- ...
- }
+ o 0
+ Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
- Das ganze fuehrt bei Ugars "nimm sand" zu folgenden
- Meldungen:
+ o NO_PNG_MSG == -1
+ Es wird keinerlei Meldung ausgegeben
- Ugar: "Du schaufelst den Sand in deine Hand."
- Raum: "Ugar schaufelt den Sand in eine Hand."
+ o Ein Array aus Strings
+ Der erste String wird an den Spieler ausgegeben, der zweite
+ (optionale) an den Raum.
-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
+ 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/props/P_PILE_NAME b/doc/props/P_PILE_NAME
index e54dc72..edb0123 100644
--- a/doc/props/P_PILE_NAME
+++ b/doc/props/P_PILE_NAME
@@ -1,9 +1,22 @@
-NAME:
- P_PILE_NAME "file_name"
-DEFINIERT IN:
- /sys/container/properties.h
+P_PILE_NAME
+***********
-BESCHREIBUNG:
- In einer Leiche der Name des Gestorbenen im Dativ. (name(WEM))
- Wird vom Haufen benoetigt.
+
+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/props/P_PLAYER_LIGHT b/doc/props/P_PLAYER_LIGHT
index ddd59b5..ce0c22d 100644
--- a/doc/props/P_PLAYER_LIGHT
+++ b/doc/props/P_PLAYER_LIGHT
@@ -1,28 +1,44 @@
-NAME:
- P_PLAYER_LIGHT "player_light"
-DEFINIERT IN:
- /sys/properties.h
+P_PLAYER_LIGHT
+**************
-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!
+NAME
+====
- 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.
+ P_PLAYER_LIGHT "player_light"
- 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()
+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/props/P_PLURAL b/doc/props/P_PLURAL
index 0a5e3a5..eed829f 100644
--- a/doc/props/P_PLURAL
+++ b/doc/props/P_PLURAL
@@ -1,39 +1,58 @@
-NAME:
- P_PLURAL "plural"
-DEFINIERT IN:
- /sys/thing/language.h
+P_PLURAL
+********
-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
+NAME
+====
-BEISPIELE:
- SetProp(P_NAME, "Stiefel"); SetProp(P_PLURAL, 2);
- name(WER, 1) -> "die zwei Stiefel"
+ P_PLURAL "plural"
- 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();
- }
+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/props/P_POISON b/doc/props/P_POISON
index 2b7ea7b..2ab5dc1 100644
--- a/doc/props/P_POISON
+++ b/doc/props/P_POISON
@@ -1,8 +1,21 @@
-NAME:
- P_POISON "poison"
-DEFINIERT IN:
- /sys/properties.h
+P_POISON
+********
-BESCHREIBUNG:
- Wie stark wir vergiftet sind (0-11)
+
+NAME
+====
+
+ P_POISON "poison"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ Wie stark wir vergiftet sind (0-11)
diff --git a/doc/props/P_POISON_DELAY b/doc/props/P_POISON_DELAY
index aba57c6..079efd9 100644
--- a/doc/props/P_POISON_DELAY
+++ b/doc/props/P_POISON_DELAY
@@ -1,13 +1,25 @@
-NAME:
- P_POISON_DELAY "poison_delay"
-DEFINIERT IN:
- /sys/living/life.h
+P_POISON_DELAY
+**************
-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.
-
+
+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/props/P_PORTIONS b/doc/props/P_PORTIONS
index cb134e6..a6bdf16 100644
--- a/doc/props/P_PORTIONS
+++ b/doc/props/P_PORTIONS
@@ -1,21 +1,39 @@
-NAME:
- P_PORTIONS "std_food_portions"
-DEFINIERT IN:
- <sys/food.h>
+P_PORTIONS
+**********
-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
+NAME
+====
-------------------------------------------------------------------------------
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
\ No newline at end of file
+ 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/props/P_POST b/doc/props/P_POST
index 53a6f74..975a884 100644
--- a/doc/props/P_POST
+++ b/doc/props/P_POST
@@ -1,64 +1,82 @@
-NAME:
- P_POST "Post"
-DEFINIERT IN:
- /mail/post.h
+P_POST
+******
-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
+NAME
+====
- Raeume, die von /std/post.c abgeleitet wurden, nutzen als Standard
- natuerlich PP_ALLOWED.
+ P_POST "Post"
-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);
- ...
- }
+DEFINIERT IN
+============
- Objekte selbst koennte man folgendermassen aus Paketen verbannen,
- welche versendet werden sollen:
+ /mail/post.h
- 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.
+BESCHREIBUNG
+============
-SIEHE AUCH:
- /std/post.c, /std/mailcabin.c, /p/service/loco/std/mailcabin.c
+ 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/props/P_POTIONROOMS b/doc/props/P_POTIONROOMS
index 5820be2..0df158f 100644
--- a/doc/props/P_POTIONROOMS
+++ b/doc/props/P_POTIONROOMS
@@ -1,19 +1,35 @@
-NAME:
- P_POTIONROOMS "potionrooms"
-DEFINIERT IN:
- /sys/player/potion.h
+P_POTIONROOMS
+*************
-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.
+NAME
+====
-SIEHE AUCH:
- Sonstiges: zaubertraenke, /secure/potionmaster.c, /room/orakel.c
- Verwandt: FindPotion(), AddKnownPotion(), RemoveKnownPotion(), InList()
- Props: P_KNOWN_POTIONROOMS
+ 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/props/P_PRAY_ROOM b/doc/props/P_PRAY_ROOM
index 3c8f9ff..ad0a469 100644
--- a/doc/props/P_PRAY_ROOM
+++ b/doc/props/P_PRAY_ROOM
@@ -1,36 +1,54 @@
-NAME:
- P_PRAY_ROOM "_lib_p_pray_room"
-DEFINIERT IN:
- /sys/player/base.h
+P_PRAY_ROOM
+***********
-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.
+NAME
+====
- 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.
+ P_PRAY_ROOM "_lib_p_pray_room"
- 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.
+DEFINIERT IN
+============
- Eine dauerhafte Aenderung des Betraums des Spielers muss mit dem EM
- Rassen und dem EM Gilden abgestimmt werden.
+ /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:
+ QueryPrayRoom(), SetDefaultPrayRoom()
+
+
+LETZTE AeNDERUNG
+================
+
21.05.2013, Zesstra
-
diff --git a/doc/props/P_PREFERED_ENEMY b/doc/props/P_PREFERED_ENEMY
index eed58e6..6b629aa 100644
--- a/doc/props/P_PREFERED_ENEMY
+++ b/doc/props/P_PREFERED_ENEMY
@@ -1,26 +1,41 @@
-NAME:
- P_PREFERED_ENEMY "pref_enemy"
-DEFINIERT IN:
- /sys/living/combat.h
+P_PREFERED_ENEMY
+****************
-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
+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/props/P_PRESAY b/doc/props/P_PRESAY
index c5ec2d2..1580b5e 100644
--- a/doc/props/P_PRESAY
+++ b/doc/props/P_PRESAY
@@ -1,9 +1,22 @@
-NAME:
- P_PRESAY "presay"
-DEFINIERT IN:
- /sys/player/description.h
+P_PRESAY
+********
-BESCHREIBUNG:
- Presay des Spielers. Erscheint vor dem Namen in Kurz/Langbeschreibung.
- Erscheint auch in name(), also in sag, ruf, teile mit usw.
+
+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/props/P_PREVENT_PILE b/doc/props/P_PREVENT_PILE
index 39ddf14..1ad6807 100644
--- a/doc/props/P_PREVENT_PILE
+++ b/doc/props/P_PREVENT_PILE
@@ -1,22 +1,34 @@
-NAME:
- P_PREVENT_PILE "prevent_pile"
-DEFINIERT IN:
- /sys/container/properties.h
+P_PREVENT_PILE
+**************
-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!
+NAME
+====
- 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.
+ 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/props/P_PRE_INFO b/doc/props/P_PRE_INFO
index 48f1d9e..099e592 100644
--- a/doc/props/P_PRE_INFO
+++ b/doc/props/P_PRE_INFO
@@ -1,55 +1,86 @@
-NAME:
- P_PRE_INFO "npc_pre_info"
-DEFINIERT IN:
- /sys/npc.h
+P_PRE_INFO
+**********
-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.
+NAME
+====
- - Closure
- => die Antwort bzw. Reaktion des NPCs obliegt ganz der
- angegebenen Closure. Diese muss dabei einen String oder
- Ganzzahlen-Wert zurueckgeben
+ P_PRE_INFO "npc_pre_info"
-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);
+DEFINIERT IN
+============
-HINWEISE:
- Bitte beachten, dass der interne Name der Property "npc_pre_info"
- ist und somit nur das Ueberschreiben von _query_npc_pre_info()
- funktioniert.
+ /sys/npc.h
-SIEHE AUCH:
- AddInfo(), /std/npc/info.c
-----------------------------------------------------------------------------
+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/props/P_PROMPT b/doc/props/P_PROMPT
index b380215..267437e 100644
--- a/doc/props/P_PROMPT
+++ b/doc/props/P_PROMPT
@@ -1,8 +1,21 @@
-NAME:
- P_PROMPT "prompt"
-DEFINIERT IN:
- /sys/player/base.h
+P_PROMPT
+********
-BESCHREIBUNG:
- Das Prompt (Nur fuer Magier).
+
+NAME
+====
+
+ P_PROMPT "prompt"
+
+
+DEFINIERT IN
+============
+
+ /sys/player/base.h
+
+
+BESCHREIBUNG
+============
+
+ Das Prompt (Nur fuer Magier).
diff --git a/doc/props/P_PUB_NOT_ON_MENU b/doc/props/P_PUB_NOT_ON_MENU
index 07029b0..8618009 100644
--- a/doc/props/P_PUB_NOT_ON_MENU
+++ b/doc/props/P_PUB_NOT_ON_MENU
@@ -1,21 +1,39 @@
-NAME:
- P_PUB_NOT_ON_MENU "pub_not_on_menu"
-DEFINIERT IN:
- /sys/pub.h
+P_PUB_NOT_ON_MENU
+*****************
-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"
+NAME
+====
-SIEHE AUCH:
- /std/room/pub.c
+ 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/props/P_PUB_NO_KEEPER b/doc/props/P_PUB_NO_KEEPER
index 8f4c26e..55c4230 100644
--- a/doc/props/P_PUB_NO_KEEPER
+++ b/doc/props/P_PUB_NO_KEEPER
@@ -1,19 +1,37 @@
-NAME:
- P_PUB_NO_KEEPER "pub_no_keeper"
-DEFINIERT IN:
- /sys/pub.h
+P_PUB_NO_KEEPER
+***************
-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"
+NAME
+====
-SIEHE AUCH:
- /std/room/pub.c
+ 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/props/P_PUB_NO_MONEY b/doc/props/P_PUB_NO_MONEY
index 9ff293a..9510b07 100644
--- a/doc/props/P_PUB_NO_MONEY
+++ b/doc/props/P_PUB_NO_MONEY
@@ -1,21 +1,39 @@
-NAME:
- P_PUB_NO_MONEY "pub_no_money"
-DEFINIERT IN:
- /sys/pub.h
+P_PUB_NO_MONEY
+**************
-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"
+NAME
+====
-SIEHE AUCH:
- /std/room/pub.c
+ 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/props/P_PUB_UNAVAILABLE b/doc/props/P_PUB_UNAVAILABLE
index 13aaa4f..7eaede7 100644
--- a/doc/props/P_PUB_UNAVAILABLE
+++ b/doc/props/P_PUB_UNAVAILABLE
@@ -1,20 +1,38 @@
-NAME:
- P_PUB_UNAVAILABLE "pub_unavailable"
-DEFINIERT IN:
- /sys/pub.h
+P_PUB_UNAVAILABLE
+*****************
-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"
+NAME
+====
-SIEHE AUCH:
- /std/room/pub.c
+ 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/props/P_PURSUERS b/doc/props/P_PURSUERS
index c35bfe2..05ead3b 100644
--- a/doc/props/P_PURSUERS
+++ b/doc/props/P_PURSUERS
@@ -1,14 +1,29 @@
-NAME:
- P_PURSUERS "pursuers"
-DEFINIERT IN:
- /sys/living/moving.h
+P_PURSUERS
+**********
-BESCHREIBUNG:
- Enthaelt Verfolger - nicht von Hand manipulieren!
-SIEHE AUCH:
- AddPursuer(L), RemovePursuer(L)
+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/props/P_PUT_MSG b/doc/props/P_PUT_MSG
index 5f6caef..65624ce 100644
--- a/doc/props/P_PUT_MSG
+++ b/doc/props/P_PUT_MSG
@@ -1,62 +1,79 @@
+
P_PUT_MSG
-NAME:
- P_PUT_MSG "put_message"
+*********
-DEFINIERT IN:
- /sys/living/put_and_get.h
-BESCHREIBUNG:
+NAME
+====
- Mit P_PUT_MSG kann man die Meldung, die man beim Hineinstecken eines
- Objektes in einen Container bekommt, modifizieren.
+ P_PUT_MSG "put_message"
- Folgende Werte sind moeglich:
- o 0
- Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
+DEFINIERT IN
+============
- o NO_PNG_MSG == -1
- Es wird keinerlei Meldung ausgegeben
+ /sys/living/put_and_get.h
- 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
+BESCHREIBUNG
+============
- Wird der zweite String nicht angegeben, erfolgt keine Meldung an den
- Raum.
+ Mit P_PUT_MSG kann man die Meldung, die man beim Hineinstecken eines
+ Objektes in einen Container bekommt, modifizieren.
-BEISPIEL:
- void create() {
- ...
- SetProp( P_SHORT, "Etwas Sand" );
- SetProp( P_LONG, break_string(
- "Ein wenig magischer Sand. Sehr feinkruemelig.",78 ));
+ Folgende Werte sind moeglich:
- SetProp( P_NAME, "Sand" );
- AddId( ({"sand"}) );
- SetProp( P_GENDER, MALE );
+ o 0
+ Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
- SetProp( P_PUT_MSG, ({
- "Du laesst @WEN2 in @WENU3 rieseln.",
- "@WER1 laesst @WEN2 in @WENU3 rieseln."}));
- ...
- }
+ o NO_PNG_MSG == -1
+ Es wird keinerlei Meldung ausgegeben
- Das ganze fuehrt bei Ugars "stecke sand in paket" zu folgenden
- Meldungen:
+ o Ein Array aus Strings
+ Der erste String wird an den Spieler ausgegeben, der zweite
+ (optionale) an den Raum.
- Ugar: "Du laesst den Sand in ein Paket rieseln."
- Raum: "Ugar laesst den Sand in ein Paket rieseln."
+ Die Strings werden durch die Funktion replace_personal() geparst.
+ Objekt1 - Spieler
+ Objekt2 - das Objekt, das irgendwohin gesteckt wird
+ Objekt3 - der Container
-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
+ 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/props/P_QP b/doc/props/P_QP
index 08fb5a4..9840586 100644
--- a/doc/props/P_QP
+++ b/doc/props/P_QP
@@ -1,13 +1,29 @@
-NAME:
- P_QP "questpoints"
-DEFINIERT IN:
- /sys/player/quest.h
+P_QP
+****
-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.
+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/props/P_QUALITY b/doc/props/P_QUALITY
index 3a4118c..a103eaf 100644
--- a/doc/props/P_QUALITY
+++ b/doc/props/P_QUALITY
@@ -1,38 +1,57 @@
+
P_QUALITY
+*********
-NAME:
- P_QUALITY "quality"
-DEFINIERT IN:
- <combat.h>
+NAME
+====
-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.
+ P_QUALITY "quality"
-BEISPIEL:
- inherit "/std/weapon";
+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()
+ {
...
- #include <combat.h>
+ SetProp(P_QUALITY,200);
+ ...
+ }
- create()
- {
- ...
- SetProp(P_QUALITY,200);
- ...
- }
+ Diese Waffe wuerde bei jedem 200. Schlag etwas beschaedigt.
- 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.
+BEMERKUNG
+=========
-SIEHE AUCH:
- /std/armour.c, /std/weapon.c, TakeFlaw(), QueryFlaw(), Damage()
+ 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/props/P_QUESTS b/doc/props/P_QUESTS
index 446ea90..84fe435 100644
--- a/doc/props/P_QUESTS
+++ b/doc/props/P_QUESTS
@@ -1,8 +1,21 @@
-NAME:
- P_QUESTS "quests"
-DEFINIERT IN:
- /sys/player/quest.h
+P_QUESTS
+********
-BESCHREIBUNG:
- Liste der geloesten Quests.
+
+NAME
+====
+
+ P_QUESTS "quests"
+
+
+DEFINIERT IN
+============
+
+ /sys/player/quest.h
+
+
+BESCHREIBUNG
+============
+
+ Liste der geloesten Quests.
diff --git a/doc/props/P_QUEST_ITEM b/doc/props/P_QUEST_ITEM
index e4eebb5..135954b 100644
--- a/doc/props/P_QUEST_ITEM
+++ b/doc/props/P_QUEST_ITEM
@@ -1,46 +1,73 @@
-NAME:
- P_QUEST_ITEM "quest_item"
-DEFINIERT IN:
- /sys/quest_items.h
+P_QUEST_ITEM
+************
-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");
+NAME
+====
- 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);
+ P_QUEST_ITEM "quest_item"
- 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.
+DEFINIERT IN
+============
-SIEHE AUCH:
- "/sys/quest_items.h"
+ /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/props/P_RACE b/doc/props/P_RACE
index 7ed77cd..c6aebc7 100644
--- a/doc/props/P_RACE
+++ b/doc/props/P_RACE
@@ -1,30 +1,48 @@
-NAME:
- P_RACE "race"
-DEFINIERT IN:
- /sys/living/description.h
+P_RACE
+******
-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
- }
+NAME
+====
-SIEHE AUCH:
- /std/npc.c, /std/pub.c
+ 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/props/P_RACESTRING b/doc/props/P_RACESTRING
index b75f46b..2a13577 100644
--- a/doc/props/P_RACESTRING
+++ b/doc/props/P_RACESTRING
@@ -1,9 +1,22 @@
-NAME:
- P_RACESTRING "racestring"
-DEFINIERT IN:
- /sys/properties.h
+P_RACESTRING
+************
-BESCHREIBUNG:
- Gibt eine dem Geschlecht angepasste Beschreibung der Rasse zurueck
- ("Zwerg" oder "Zwergin" etc.)
+
+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/props/P_RACE_DESCRIPTION b/doc/props/P_RACE_DESCRIPTION
index 5b2ebfb..ca1f576 100644
--- a/doc/props/P_RACE_DESCRIPTION
+++ b/doc/props/P_RACE_DESCRIPTION
@@ -1,8 +1,21 @@
-NAME:
- P_RACE_DESCRIPTION "racedescr"
-DEFINIERT IN:
- /sys/properties.h
+P_RACE_DESCRIPTION
+******************
-BESCHREIBUNG:
- Beschreibung der Vor/Nachteile einer Rasse.
+
+NAME
+====
+
+ P_RACE_DESCRIPTION "racedescr"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ Beschreibung der Vor/Nachteile einer Rasse.
diff --git a/doc/props/P_RANGE b/doc/props/P_RANGE
index 7fd5268..2fabc63 100644
--- a/doc/props/P_RANGE
+++ b/doc/props/P_RANGE
@@ -1,26 +1,43 @@
+
P_RANGE
+*******
-NAME:
- P_RANGE "range"
-DEFINIERT IN:
- <combat.h>
+NAME
+====
-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.
+ P_RANGE "range"
-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
+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/props/P_READ_DETAILS b/doc/props/P_READ_DETAILS
index 035a2cc..06a7598 100644
--- a/doc/props/P_READ_DETAILS
+++ b/doc/props/P_READ_DETAILS
@@ -1,21 +1,40 @@
-NAME:
- P_READ_DETAILS "read_details"
-DEFINIERT IN:
- /sys/thing/description.h
+P_READ_DETAILS
+**************
-BESCHREIBUNG:
- Mapping mit den Daten der Details, die durch Lesen ermittelt werden
- koennen.
-BEMERKUNGEN:
- Bitte nur mit den entsprechenden Methoden veraendern!
+NAME
+====
-SIEHE AUCH:
- Setzen: AddReadDetail()
- Loeschen: RemoveReadDetail()
- Aehnlich: AddDetail(), P_DETAILS
- Veraltet: P_READ_MSG
- Sonstiges: GetDetail(), break_string()
+ P_READ_DETAILS "read_details"
-27. Jan 2013 Gloinson
\ No newline at end of file
+
+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/props/P_READ_NEWS b/doc/props/P_READ_NEWS
index b64a252..8c69c89 100644
--- a/doc/props/P_READ_NEWS
+++ b/doc/props/P_READ_NEWS
@@ -1,8 +1,21 @@
-NAME:
- P_READ_NEWS "read_news"
-DEFINIERT IN:
- /sys/player/base.h
+P_READ_NEWS
+***********
-BESCHREIBUNG:
- Welche Artikel bereits gelesen wurde (frueher: in der MPA)
+
+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/props/P_REAL_RACE b/doc/props/P_REAL_RACE
index 88279a6..39c196a 100644
--- a/doc/props/P_REAL_RACE
+++ b/doc/props/P_REAL_RACE
@@ -1,72 +1,95 @@
-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()));
+P_REAL_RACE
+***********
- 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;
+NAME
+====
- 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;
+ P_REAL_RACE "real_race"
- 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
+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/props/P_REFERENCE_OBJECT b/doc/props/P_REFERENCE_OBJECT
index e2a6405..9187a49 100644
--- a/doc/props/P_REFERENCE_OBJECT
+++ b/doc/props/P_REFERENCE_OBJECT
@@ -1,27 +1,41 @@
+
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.
+NAME
+====
- 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.
+ P_REFERENCE_OBJECT "reference_object"
- 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()
+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/props/P_REJECT b/doc/props/P_REJECT
index 4af07f3..072bdab 100644
--- a/doc/props/P_REJECT
+++ b/doc/props/P_REJECT
@@ -1,51 +1,72 @@
-NAME:
- P_REJECT "reject"
-DEFINIERT IN:
- /sys/properties.h
+P_REJECT
+********
-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.
+NAME
+====
-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!
+ P_REJECT "reject"
-SIEHE AUCH:
- give_notify(), /std/npc/put_and_get.c
------------------------------------------------------------------------------
+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/props/P_REMOVE_FUNC b/doc/props/P_REMOVE_FUNC
index 2d431fa..f5c2232 100644
--- a/doc/props/P_REMOVE_FUNC
+++ b/doc/props/P_REMOVE_FUNC
@@ -1,25 +1,40 @@
+
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
\ No newline at end of file
+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/props/P_REMOVE_MSG b/doc/props/P_REMOVE_MSG
index 9eb1d8d..78a1357 100644
--- a/doc/props/P_REMOVE_MSG
+++ b/doc/props/P_REMOVE_MSG
@@ -1,28 +1,49 @@
-NAME:
- P_REMOVE_MSG "std_food_remove_msg"
-DEFINIERT IN:
- <sys/food.h>
+P_REMOVE_MSG
+************
-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
+NAME
+====
-------------------------------------------------------------------------------
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
\ No newline at end of file
+ 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/props/P_RESET_LIFETIME b/doc/props/P_RESET_LIFETIME
index 378cf0c..bbd4bbe 100644
--- a/doc/props/P_RESET_LIFETIME
+++ b/doc/props/P_RESET_LIFETIME
@@ -1,31 +1,52 @@
-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
\ No newline at end of file
+
+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/props/P_RESISTANCE b/doc/props/P_RESISTANCE
index ff3de74..48e476f 100644
--- a/doc/props/P_RESISTANCE
+++ b/doc/props/P_RESISTANCE
@@ -1,37 +1,61 @@
+
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.
+NAME
+====
-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.
+ P_RESISTANCE "resistance"
-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}));
+DEFINIERT IN
+============
-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
+ /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/props/P_RESISTANCE_MODIFIER b/doc/props/P_RESISTANCE_MODIFIER
index 0a0538e..2a3322e 100644
--- a/doc/props/P_RESISTANCE_MODIFIER
+++ b/doc/props/P_RESISTANCE_MODIFIER
@@ -1,26 +1,45 @@
-NAME:
- P_RESISTANCE_MODIFIER "rstr:mod"
-DEFINIERT IN:
- /sys/living/combat.h
+P_RESISTANCE_MODIFIER
+*********************
-BESCHREIBUNG:
- Hier werden die Resistenzmodifikatoren in einem Mapping abgespeichert.
- Format:
+NAME
+====
- (["me":<Aufaddition aller Resistenz/Empfindlichkeitsmodifikationen>;0,
- "<Objektname>#<Schluessel>":<Resistenzmapping>;<Objekreferenz>,
- ...])
+ P_RESISTANCE_MODIFIER "rstr:mod"
-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
+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/props/P_RESISTANCE_STRENGTHS b/doc/props/P_RESISTANCE_STRENGTHS
index ed24d2d..4a93f08 100644
--- a/doc/props/P_RESISTANCE_STRENGTHS
+++ b/doc/props/P_RESISTANCE_STRENGTHS
@@ -1,92 +1,114 @@
-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.
+P_RESISTANCE_STRENGTHS
+**********************
- // eine Eisruestung
- SetProp(P_RESISTANCE_STRENGTHS, ([DT_COLD:50, DT_FIRE:-100]));
+NAME
+====
- 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).
+ P_RESISTANCE_STRENGTHS "resistance_strengths"
- ! 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
+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/props/P_RESTRICTIONS b/doc/props/P_RESTRICTIONS
index 34890ff..a1764b9 100644
--- a/doc/props/P_RESTRICTIONS
+++ b/doc/props/P_RESTRICTIONS
@@ -1,140 +1,163 @@
-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.
+P_RESTRICTIONS
+**************
+NAME
+====
-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.
+ P_RESTRICTIONS "restrictions"
- 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]));
+DEFINIERT IN
+============
- Komplexeres Beispiel
+ /sys/combat.h
+ (Die SR_*-Parameter sind in /sys/new_skills.h definiert.)
- 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
+BESCHREIBUNG
+============
-LETZTE AeNDERUNG:
-03. Januar 2014, Arathorn
+ 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/props/P_ROOM_MSG b/doc/props/P_ROOM_MSG
index c3324f2..3486458 100644
--- a/doc/props/P_ROOM_MSG
+++ b/doc/props/P_ROOM_MSG
@@ -1,20 +1,39 @@
-NAME:
- P_ROOM_MSG "room_msg"
-DEFINIERT IN:
- /sys/room/description.h
+P_ROOM_MSG
+**********
-BESCHREIBUNG:
- Liste mit Meldungen, die zufaellig im Raum ausgegeben werden.
- Hier sind nur die Textmeldungen als String-Array gespeichert.
+NAME
+====
-ANMERKUNGEN:
- Bitte AddRoomMessage() zum Hinzufuegen/Ueberschreiben benutzen!
+ P_ROOM_MSG "room_msg"
-SIEHE AUCH:
- LFuns: AddRoomMessage()
- Verwandt: tell_room(), ReceiveMsg()
- Props: P_FUNC_MSG, P_MSG_PROB
+
+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/props/P_ROOM_TYPE b/doc/props/P_ROOM_TYPE
index d9dd746..22e894e 100644
--- a/doc/props/P_ROOM_TYPE
+++ b/doc/props/P_ROOM_TYPE
@@ -1,23 +1,39 @@
-NAME:
- P_ROOM_TYPE "room_type"
-DEFINIERT IN:
- /sys/rooms.h
+P_ROOM_TYPE
+***********
-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
+NAME
+====
-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:
+ P_ROOM_TYPE "room_type"
- if ( environment() &&
- environment()->QueryProp(P_ROOM_TYPE) & RT_PUB ){
- ... tanken ...
- }
+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/props/P_SB_SPELLS b/doc/props/P_SB_SPELLS
index 84aa723..1ffac9d 100644
--- a/doc/props/P_SB_SPELLS
+++ b/doc/props/P_SB_SPELLS
@@ -1,23 +1,42 @@
-NAME:
- P_SB_SPELLS "sb_spells"
-DEFINIERT IN:
- /sys/new_skills.h
+P_SB_SPELLS
+***********
-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.
+NAME
+====
-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
+ P_SB_SPELLS "sb_spells"
-Last modified: Wed Jan 14 19:17:06 1998 by Patryn
\ No newline at end of file
+
+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/props/P_SCREENSIZE b/doc/props/P_SCREENSIZE
index fc9dd15..e54ee8b 100644
--- a/doc/props/P_SCREENSIZE
+++ b/doc/props/P_SCREENSIZE
@@ -1,8 +1,21 @@
-NAME:
- P_SCREENSIZE "screensize"
-DEFINIERT IN:
- /sys/player/base.h
+P_SCREENSIZE
+************
-BESCHREIBUNG:
- Bildschirmgroesse in Zeilen (fuer More)
+
+NAME
+====
+
+ P_SCREENSIZE "screensize"
+
+
+DEFINIERT IN
+============
+
+ /sys/player/base.h
+
+
+BESCHREIBUNG
+============
+
+ Bildschirmgroesse in Zeilen (fuer More)
diff --git a/doc/props/P_SECOND b/doc/props/P_SECOND
index 4aa835a..69c97d6 100644
--- a/doc/props/P_SECOND
+++ b/doc/props/P_SECOND
@@ -1,21 +1,39 @@
-NAME:
- P_SECOND "second"
-DEFINIERT IN:
- /sys/player/base.h
+P_SECOND
+********
-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");
- }
+NAME
+====
-SIEHE AUCH:
- Properties: P_SECOND_MARK
- Sonstiges: /secure/zweities.c
+ 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/props/P_SECOND_MARK b/doc/props/P_SECOND_MARK
index c1c0c42..dd2c68a 100644
--- a/doc/props/P_SECOND_MARK
+++ b/doc/props/P_SECOND_MARK
@@ -1,18 +1,31 @@
-NAME:
- P_SECOND_MARK "second_mark"
-DEFINIERT IN:
- /sys/player/base.h
+P_SECOND_MARK
+*************
-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.
+NAME
+====
- 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.
+ P_SECOND_MARK "second_mark"
- 1 Markierung 'sichtbar + Name'; wie 0, nur dass beim Fingern alle
- Spieler den Namen des Ersties sehen koennen.
+
+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/props/P_SEERDOORS b/doc/props/P_SEERDOORS
index 8ffb852..8ec02e7 100644
--- a/doc/props/P_SEERDOORS
+++ b/doc/props/P_SEERDOORS
@@ -1,26 +1,45 @@
+
P_SEERDOORS
+***********
-NAME:
- P_SEERDOORS "rw_sehertore"
-DEFINIERT IN:
- /d/seher/portale/sehertor.h
+NAME
+====
-BESCHREIBUNG:
- Sehertor-relevante Property.
+ P_SEERDOORS "rw_sehertore"
- 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
-
+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/props/P_SEERDOOR_ALLOWED b/doc/props/P_SEERDOOR_ALLOWED
index b8225e3..12f062b 100644
--- a/doc/props/P_SEERDOOR_ALLOWED
+++ b/doc/props/P_SEERDOOR_ALLOWED
@@ -1,15 +1,27 @@
-NAME:
- P_SEERDOOR_ALLOWED "rw_sehertor_erlaubt"
-DEFINIERT IN:
- /d/seher/portale/sehertor.h
+P_SEERDOOR_ALLOWED
+******************
-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.
+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/props/P_SENSITIVE b/doc/props/P_SENSITIVE
index 23d1fee..c1e8051 100644
--- a/doc/props/P_SENSITIVE
+++ b/doc/props/P_SENSITIVE
@@ -1,125 +1,154 @@
+
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.
+NAME
+====
- 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.
+ P_SENSITIVE "sensitive"
- 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.
+DEFINIERT IN
+============
-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.
+ /sys/thing/moving.h
-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:
+BESCHREIBUNG
+============
- void create() {
- SetProp( P_SENSITIVE, ({ ({SENSITIVE_ATTACK, DT_FIRE, 100}),
- ({SENSITIVE_INVENTORY, DT_FIRE, 100}) }) );
- [...]
+ 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();
+ }
- varargs void trigger_sensitive_attack() {
- 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
- 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();
- }
+SIEHE AUCH
+==========
- - 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
+ 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/props/P_SENSITIVE_ATTACK b/doc/props/P_SENSITIVE_ATTACK
index b1586eb..168c15b 100644
--- a/doc/props/P_SENSITIVE_ATTACK
+++ b/doc/props/P_SENSITIVE_ATTACK
@@ -1,24 +1,42 @@
+
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.
+NAME
+====
-BEMERKUNGEN:
- Nicht selbst veraendern - bitte P_SENSITIVE fuer Eintraege benutzen.
+ P_SENSITIVE_ATTACK "sensitive_attack"
-SIEHE AUCH:
- P_SENSITIVE
- InsertSensitiveObject, RemoveSensitiveObject
- insert_sensitive_inv_trigger, insert_sensitive_inv
- P_SENSITIVE_INVENTORY_TRIGGER, P_SENSITIVE_INVENTORY
- CheckSensitiveAttack
+
+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/props/P_SENSITIVE_INVENTORY b/doc/props/P_SENSITIVE_INVENTORY
index 1e75423..418f9a1 100644
--- a/doc/props/P_SENSITIVE_INVENTORY
+++ b/doc/props/P_SENSITIVE_INVENTORY
@@ -1,24 +1,43 @@
-NAME:
- P_SENSITIVE_INVENTORY "sensitive_inv"
-DEFINIERT IN:
- /sys/sensitive.h
+P_SENSITIVE_INVENTORY
+*********************
-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.
+NAME
+====
-SIEHE AUCH:
- P_SENSITIVE
- InsertSensitiveObject, RemoveSensitiveObject
- insert_sensitive_inv_trigger, insert_sensitive_inv
- P_SENSITIVE_INVENTORY_TRIGGER, P_SENSITIVE_ATTACK
- CheckSensitiveAttack
+ 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/props/P_SENSITIVE_INVENTORY_TRIGGER b/doc/props/P_SENSITIVE_INVENTORY_TRIGGER
index df6feae..627a582 100644
--- a/doc/props/P_SENSITIVE_INVENTORY_TRIGGER
+++ b/doc/props/P_SENSITIVE_INVENTORY_TRIGGER
@@ -1,24 +1,42 @@
+
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.
+NAME
+====
-BEMERKUNGEN:
- Nicht selbst veraendern - bitte P_SENSITIVE fuer Eintraege benutzen.
+ P_SENSITIVE_INVENTORY_TRIGGER "sensitive_inv_trigger"
-SIEHE AUCH:
- P_SENSITIVE
- InsertSensitiveObject, RemoveSensitiveObject
- insert_sensitive_inv_trigger, insert_sensitive_inv
- P_SENSITIVE_ATTACK, P_SENSITIVE_INVENTORY
- CheckSensitiveAttack
+
+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/props/P_SHOOTING_AREA b/doc/props/P_SHOOTING_AREA
index 770564f..9339847 100644
--- a/doc/props/P_SHOOTING_AREA
+++ b/doc/props/P_SHOOTING_AREA
@@ -1,24 +1,38 @@
+
P_SHOOTING_AREA
+***************
-NAME:
- P_SHOOTING_AREA "shooting_area"
-DEFINIERT IN:
- <combat.h>
+NAME
+====
-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.
+ P_SHOOTING_AREA "shooting_area"
- 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
+DEFINIERT IN
+============
-29.Jul 2014 Gloinson
\ No newline at end of file
+ <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/props/P_SHOOTING_WC b/doc/props/P_SHOOTING_WC
index 35ca215..6345d76 100644
--- a/doc/props/P_SHOOTING_WC
+++ b/doc/props/P_SHOOTING_WC
@@ -1,31 +1,48 @@
+
P_SHOOTING_WC
+*************
-NAME:
- P_SHOOTING_WC "shooting_wc"
-DEFINIERT IN:
- <combat.h>
+NAME
+====
-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.
+ P_SHOOTING_WC "shooting_wc"
-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
+DEFINIERT IN
+============
- // So haetten Langbogen mit Aluminiumpfeil eine P_SHOOTING_WC von 70+60.
+ <combat.h>
-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
\ No newline at end of file
+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/props/P_SHORT b/doc/props/P_SHORT
index b6502d4..49b2603 100644
--- a/doc/props/P_SHORT
+++ b/doc/props/P_SHORT
@@ -1,41 +1,60 @@
+
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).
+NAME
+====
- ACHTUNG: Die Kurzbeschreibung sollte dabei weder mit einem
- Satzzeichen noch mit einem "\n" abgeschlossen sein
- (dies wird von den zustaendigen Funktionen erledigt).
+ P_SHORT "short"
- 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.
+DEFINIERT IN
+============
-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.
+ /sys/thing/description.h
-BEISPIELE:
- // eine Axt sieht natuerlich so aus:
- SetProp(P_SHORT, "Eine Axt");
-SIEHE AUCH:
- Aehnliches: P_LONG, short()
- Sonstiges: P_INT_SHORT, process_string()
+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/props/P_SHORT_CWD b/doc/props/P_SHORT_CWD
index a6343ae..46f0236 100644
--- a/doc/props/P_SHORT_CWD
+++ b/doc/props/P_SHORT_CWD
@@ -1,8 +1,21 @@
-NAME:
- P_SHORT_CWD "short_cwd"
-DEFINIERT IN:
- /sys/shells.h
+P_SHORT_CWD
+***********
-BESCHREIBUNG:
- .readme bei cd ausgeben oder nicht
+
+NAME
+====
+
+ P_SHORT_CWD "short_cwd"
+
+
+DEFINIERT IN
+============
+
+ /sys/shells.h
+
+
+BESCHREIBUNG
+============
+
+ .readme bei cd ausgeben oder nicht
diff --git a/doc/props/P_SHOWEMAIL b/doc/props/P_SHOWEMAIL
index 82d1348..b6cf580 100644
--- a/doc/props/P_SHOWEMAIL
+++ b/doc/props/P_SHOWEMAIL
@@ -1,10 +1,23 @@
-NAME:
- P_SHOWEMAIL "showemail"
-DEFINIERT IN:
- /sys/player/base.h
+P_SHOWEMAIL
+***********
-BESCHREIBUNG:
- Eintrag, wer die E-Mail im "finger" zu sehen bekommen soll:
- 0, "alle", "freunde"
- Kann durch "emailanzeige" (/std/player/base.c) geaendert werden.
+
+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/props/P_SHOW_ALIAS_PROCESSING b/doc/props/P_SHOW_ALIAS_PROCESSING
index cb49cf8..94552dd 100644
--- a/doc/props/P_SHOW_ALIAS_PROCESSING
+++ b/doc/props/P_SHOW_ALIAS_PROCESSING
@@ -1,8 +1,21 @@
-NAME:
- P_SHOW_ALIAS_PROCESSING "show_alias_processing"
-DEFINIERT IN:
- /sys/player.h
+P_SHOW_ALIAS_PROCESSING
+***********************
-BESCHREIBUNG:
- Arbeit des Parsers beobachten (debugging)
+
+NAME
+====
+
+ P_SHOW_ALIAS_PROCESSING "show_alias_processing"
+
+
+DEFINIERT IN
+============
+
+ /sys/player.h
+
+
+BESCHREIBUNG
+============
+
+ Arbeit des Parsers beobachten (debugging)
diff --git a/doc/props/P_SHOW_EXITS b/doc/props/P_SHOW_EXITS
index 9c8d87b..0e00886 100644
--- a/doc/props/P_SHOW_EXITS
+++ b/doc/props/P_SHOW_EXITS
@@ -1,15 +1,31 @@
-NAME:
- P_SHOW_EXITS "show_exits"
-DEFINIERT IN:
- /sys/player/base.h
+P_SHOW_EXITS
+************
-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()
+NAME
+====
-11. Mai 2004 Gloinson
\ No newline at end of file
+ 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/props/P_SHOW_INV b/doc/props/P_SHOW_INV
index 73a2ffe..e982154 100644
--- a/doc/props/P_SHOW_INV
+++ b/doc/props/P_SHOW_INV
@@ -1,19 +1,32 @@
+
P_SHOW_INV
+**********
-NAME:
- P_SHOW_INV "show_inv"
-DEFINIERT IN:
- <thing/description.h>
+NAME
+====
-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.
+ P_SHOW_INV "show_inv"
-SIEHE AUCH:
- /std/thing/description.c
-----------------------------------------------------------------------------
+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/props/P_SHOW_MSG b/doc/props/P_SHOW_MSG
index 8841154..c19c49f 100644
--- a/doc/props/P_SHOW_MSG
+++ b/doc/props/P_SHOW_MSG
@@ -1,51 +1,69 @@
+
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.
+NAME
+====
- Folgende Werte sind moeglich:
+ P_SHOW_MSG "show_message"
- o 0
- Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
- o NO_PNG_MSG == -1
- Es wird keinerlei Meldung ausgegeben
+DEFINIERT IN
+============
- 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.
+ /sys/living/put_and_get.h
- 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.
+BESCHREIBUNG
+============
-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."
- }));
+ Mit P_SHOW_MSG kann man die Meldungen, die beim Vorzeigen eines Objektes
+ ausgegeben werden, modifizieren.
- Das fuehrt bei Ugars "zeig peter medaille" zu folgenden Meldungen:
+ Folgende Werte sind moeglich:
- 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."
+ o 0
+ Es wird eine Standardmeldung ausgegeben. Dies ist Voreinstellung.
-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
+ 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/props/P_SIBLINGS b/doc/props/P_SIBLINGS
index 15d0977..6e18f0c 100644
--- a/doc/props/P_SIBLINGS
+++ b/doc/props/P_SIBLINGS
@@ -1,9 +1,22 @@
-NAME:
- P_SIBLINGS "siblings"
-DEFINIERT IN:
- /sys/player/base.h
+P_SIBLINGS
+**********
-BESCHREIBUNG:
- Enthaelt einen String mit den Blutsbruedern eines Spielers
- (sofern vorhanden).
+
+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/props/P_SIZE b/doc/props/P_SIZE
index b5fdb72..aa311f3 100644
--- a/doc/props/P_SIZE
+++ b/doc/props/P_SIZE
@@ -1,31 +1,50 @@
-NAME:
- P_SIZE "size"
-DEFINIERT IN:
- /sys/properties.h
+P_SIZE
+******
-BESCHREIBUNG:
- Groesse des Lebewesens bzw. Laenge der Waffe (in cm).
- Wird keine Waffenlaenge explizit angegeben, so sind die Defaultwerte
- fuer die entsprechenden Waffentypen folgende:
+NAME
+====
- WT_SWORD : 100
- WT_AXE : 80
- WT_CLUB : 80
- WT_SPEAR : 180
- WT_KNIFE : 20
- WT_WHIP : 200
- WT_STAFF : 150
+ P_SIZE "size"
-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
+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/props/P_SKILLS b/doc/props/P_SKILLS
index 02a76c7..492cbbe 100644
--- a/doc/props/P_SKILLS
+++ b/doc/props/P_SKILLS
@@ -1,15 +1,30 @@
-NAME:
- P_SKILLS "skills"
-DEFINIERT IN:
- /sys/player/skills.h
+P_SKILLS
+********
-BESCHREIBUNG:
- Diese Property sollte nicht mehr verwendet werden. Sie wurde
- vollstaendig durch P_NEWSKILLS ersetzt.
-SIEHE AUCH:
- P_NEW_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/props/P_SKILL_ATTRIBUTES b/doc/props/P_SKILL_ATTRIBUTES
index 6eb5b97..066bd78 100644
--- a/doc/props/P_SKILL_ATTRIBUTES
+++ b/doc/props/P_SKILL_ATTRIBUTES
@@ -1,50 +1,69 @@
-NAME:
- P_SKILL_ATTRIBUTES "skill_attr"
-DEFINIERT IN:
- /sys/living/skill_attributes.h
+P_SKILL_ATTRIBUTES
+******************
-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: ({...}); ([]); ([]),
- ])
+NAME
+====
-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.
+ P_SKILL_ATTRIBUTES "skill_attr"
-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
\ No newline at end of file
+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/props/P_SKILL_ATTRIBUTE_OFFSETS b/doc/props/P_SKILL_ATTRIBUTE_OFFSETS
index 2568f76..6bfcad3 100644
--- a/doc/props/P_SKILL_ATTRIBUTE_OFFSETS
+++ b/doc/props/P_SKILL_ATTRIBUTE_OFFSETS
@@ -1,32 +1,49 @@
-NAME:
- P_SKILL_ATTRIBUTE_OFFSETS "skill_attr_offsets"
-DEFINIERT IN:
- /sys/living/skill_attributes.h
+P_SKILL_ATTRIBUTE_OFFSETS
+*************************
-BESHREIBUNG:
- Der Wert der Property ist ein Mapping: ([Attributname: Wert])
- In dieser Property stehen permanente Abweichungen der Skillattribute
- vom Standardwert 100.
+NAME
+====
- Zu den Moeglichen Attributwerten, siehe P_SKILL_ATTRIBUTES.
+ P_SKILL_ATTRIBUTE_OFFSETS "skill_attr_offsets"
- 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!
+DEFINIERT IN
+============
-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
+ /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/props/P_SMELLS b/doc/props/P_SMELLS
index b510ce1..0098bd8 100644
--- a/doc/props/P_SMELLS
+++ b/doc/props/P_SMELLS
@@ -1,24 +1,43 @@
-NAME:
- P_SMELLS "smell_details"
-DEFINIERT IN:
- /sys/thing/description.h
+P_SMELLS
+********
-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.
+NAME
+====
-SIEHE AUCH:
- Setzen: AddSmells()
- Loeschen: RemoveSmells()
- Aehnlich: AddDetail(), P_DETAILS
- Sonstiges: GetDetail(), break_string()
+ P_SMELLS "smell_details"
-27. Jan 2013 Gloinson
\ No newline at end of file
+
+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/props/P_SNOOPFLAGS b/doc/props/P_SNOOPFLAGS
index 4c47e39..340dde2 100644
--- a/doc/props/P_SNOOPFLAGS
+++ b/doc/props/P_SNOOPFLAGS
@@ -1,8 +1,21 @@
-NAME:
- P_SNOOPFLAGS "snoopflags"
-DEFINIERT IN:
- /sys/snooping.h
+P_SNOOPFLAGS
+************
-BESCHREIBUNG:
- *** KEINE BESCHREIBUNG VORHANDEN ***
+
+NAME
+====
+
+ P_SNOOPFLAGS "snoopflags"
+
+
+DEFINIERT IN
+============
+
+ /sys/snooping.h
+
+
+BESCHREIBUNG
+============
+
+ *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/props/P_SOUNDS b/doc/props/P_SOUNDS
index 9b9a350..520265b 100644
--- a/doc/props/P_SOUNDS
+++ b/doc/props/P_SOUNDS
@@ -1,24 +1,43 @@
-NAME:
- P_SOUNDS "sound_details"
-DEFINIERT IN:
- /sys/thing/description.h
+P_SOUNDS
+********
-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.
+NAME
+====
-SIEHE AUCH:
- Setzen: AddSounds()
- Loeschen: RemoveSounds()
- Aehnlich: AddDetail(), P_DETAILS
- Sonstiges: GetDetail(), break_string()
+ P_SOUNDS "sound_details"
-27. Jan 2013 Gloinson
\ No newline at end of file
+
+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/props/P_SP b/doc/props/P_SP
index 02bab65..fa30cb1 100644
--- a/doc/props/P_SP
+++ b/doc/props/P_SP
@@ -1,23 +1,37 @@
-NAME:
- P_SP "sp"
-DEFINIERT IN:
- /sys/living/life.h
+P_SP
+****
-BESCHREIBUNG:
- - Lebewesen
- Anzahl der Konzentrationspunkte des Wesens.
+NAME
+====
- - Speisen/Kneipen
- Heilwirkung einer Portion der Speise auf die Konzentrationspunkte
- des Konsumenten
+ P_SP "sp"
-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
\ No newline at end of file
+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/props/P_SPECIAL_DETAILS b/doc/props/P_SPECIAL_DETAILS
index 2eb2123..9b3f63c 100644
--- a/doc/props/P_SPECIAL_DETAILS
+++ b/doc/props/P_SPECIAL_DETAILS
@@ -1,23 +1,42 @@
-NAME:
- P_SPECIAL_DETAILS "special_details"
-DEFINIERT IN:
- /sys/thing/description.h
+P_SPECIAL_DETAILS
+*****************
-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.
+NAME
+====
-SIEHE AUCH:
- Setzen: AddDetail()
- Loeschen: RemoveDetail()
- Daten: P_DETAILS
- Veraltet: AddSpecialDetail(), RemoveSpecialDetail()
- Sonstiges: GetDetail(), break_string()
+ P_SPECIAL_DETAILS "special_details"
-27. Jan 2013 Gloinson
\ No newline at end of file
+
+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/props/P_SPECIAL_EXITS b/doc/props/P_SPECIAL_EXITS
index 4672024..3f2a7a5 100644
--- a/doc/props/P_SPECIAL_EXITS
+++ b/doc/props/P_SPECIAL_EXITS
@@ -1,28 +1,51 @@
-NAME:
- P_SPECIAL_EXITS "special_exits"
-DEFINIERT IN:
- /sys/properties.h
+P_SPECIAL_EXITS
+***************
-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!
+NAME
+====
-SIEHE AUCH:
- AddExit(), AddSpecialExit(), GetExits(),
- RemoveExit(), RemoveSpecialExit(),
- GuardExit(),
- H_HOOK_EXIT_USE, P_EXITS, P_HIDE_EXITS, /std/room/exits.c
- ausgaenge
+ 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/props/P_SPELLRATE b/doc/props/P_SPELLRATE
index 1672a33..1a3e5a2 100644
--- a/doc/props/P_SPELLRATE
+++ b/doc/props/P_SPELLRATE
@@ -1,8 +1,21 @@
-NAME:
- P_SPELLRATE "spellrate"
-DEFINIERT IN:
- /sys/properties.h
+P_SPELLRATE
+***********
-BESCHREIBUNG:
- NPC-Spellrate (in %)
+
+NAME
+====
+
+ P_SPELLRATE "spellrate"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ NPC-Spellrate (in %)
diff --git a/doc/props/P_SPELLS b/doc/props/P_SPELLS
index 17112fb..647daf4 100644
--- a/doc/props/P_SPELLS
+++ b/doc/props/P_SPELLS
@@ -1,8 +1,21 @@
-NAME:
- P_SPELLS "spells"
-DEFINIERT IN:
- /sys/properties.h
+P_SPELLS
+********
-BESCHREIBUNG:
- NPC-Spells
+
+NAME
+====
+
+ P_SPELLS "spells"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ NPC-Spells
diff --git a/doc/props/P_SP_DELAY b/doc/props/P_SP_DELAY
index 84f6372..aa74360 100644
--- a/doc/props/P_SP_DELAY
+++ b/doc/props/P_SP_DELAY
@@ -1,10 +1,23 @@
-NAME:
- P_SP_DELAY "sp_delay"
-DEFINIERT IN:
- /sys/living/life.h
+P_SP_DELAY
+**********
-BESCHREIBUNG:
- Anzahl der heart_beats, bis die Magiepunkte um einen Punkt steigen.
- Aenderungen dieser Property in Spielern beduerfen der
- Genehmigung des EM fuer Balance.
+
+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/props/P_START_HOME b/doc/props/P_START_HOME
index 25fff2c..fd80124 100644
--- a/doc/props/P_START_HOME
+++ b/doc/props/P_START_HOME
@@ -1,8 +1,21 @@
-NAME:
- P_START_HOME "start_home"
-DEFINIERT IN:
- /sys/player/base.h
+P_START_HOME
+************
-BESCHREIBUNG:
- Raum, in dem der Spieler nach dem Einloggen landen soll
+
+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/props/P_STD_OBJECT b/doc/props/P_STD_OBJECT
index 87e21da..7c66296 100644
--- a/doc/props/P_STD_OBJECT
+++ b/doc/props/P_STD_OBJECT
@@ -1,11 +1,24 @@
-NAME:
- P_STD_OBJECT "std_object"
-DEFINIERT IN:
- /sys/v_compiler.h
+P_STD_OBJECT
+************
-BESCHREIBUNG:
- Enthaelt den Namen eines Files welches als Standard-Objekt fuer den
+
+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
@@ -13,14 +26,19 @@
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.
+ 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:
+
+BEISPIEL
+========
+
(create eines VCs)
protected void create() {
...
@@ -29,10 +47,13 @@
}
Was in diesem std_raum.c nun steht, wird in jedem VC-Clone
- verfuegbar. Sei es Details, Gerueche, auch Objekte die per
+ verfuegbar. Sei es Details, Gerueche, auch Objekte die per
AddItem eingebunden sind, ...
-SIEHE AUCH:
+
+SIEHE AUCH
+==========
+
P_COMPILER_PATH, virtual_compiler
------------------------------------------------------------------------
+
Letzte Aenderung: 22.10.07 von Zesstra
diff --git a/doc/props/P_STORE_CONSUME b/doc/props/P_STORE_CONSUME
index 7b65641..8a9afd9 100644
--- a/doc/props/P_STORE_CONSUME
+++ b/doc/props/P_STORE_CONSUME
@@ -1,51 +1,69 @@
-NAME:
- P_STORE_CONSUME "store_consume"
-DEFINIERT IN:
- /sys/bank.h
+P_STORE_CONSUME
+***************
-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.
+NAME
+====
-SIEHE AUCH:
- P_MIN_STOCK, SetStorageRoom(), /std/store.c, /std/shop.c
- AddItem(), RemoveItem(), AddFixedObject(), RemoveFixedObject()
+ P_STORE_CONSUME "store_consume"
-----------------------------------------------------------------------------
-Last modified: 19-Jun-2015, Arathorn
+
+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/props/P_STRETCH_TIME b/doc/props/P_STRETCH_TIME
index dfef4f1..1b38b7e 100644
--- a/doc/props/P_STRETCH_TIME
+++ b/doc/props/P_STRETCH_TIME
@@ -1,20 +1,34 @@
+
P_STRETCH_TIME
+**************
-NAME:
- P_STRETCH_TIME "stretch_time"
-DEFINIERT IN:
- <combat.h>
+NAME
+====
-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).
+ P_STRETCH_TIME "stretch_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
\ No newline at end of file
+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/props/P_SUBGUILD_TITLE b/doc/props/P_SUBGUILD_TITLE
index 58a59d5..83515d7 100644
--- a/doc/props/P_SUBGUILD_TITLE
+++ b/doc/props/P_SUBGUILD_TITLE
@@ -1,20 +1,38 @@
+
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.
+NAME
+====
-BEMERKUNGEN:
- Inhalt der Property kann 0 sein oder ein String. Ein Zusatztitel kann
- mittels P_VISIBLE_SUBGUILD_TITLE vorgetaeuscht werden.
+ P_SUBGUILD_TITLE "subguild_title"
-SIEHE AUCH:
- P_GUILD_TITLE, P_VISIBLE_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/props/P_SYNTAX_HELP b/doc/props/P_SYNTAX_HELP
index 13344f1..a796fb5 100644
--- a/doc/props/P_SYNTAX_HELP
+++ b/doc/props/P_SYNTAX_HELP
@@ -1,44 +1,62 @@
-NAME:
- P_SYNTAX_HELP "lib_p_syntax_help"
-DEFINIERT IN:
- /sys/thing/commands.h
+P_SYNTAX_HELP
+*************
-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.
+NAME
+====
- 2) ein Array: ({hilfetext, bedingungen})
+ P_SYNTAX_HELP "lib_p_syntax_help"
- <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.
+DEFINIERT IN
+============
-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).
+ /sys/thing/commands.h
-SIEHE AUCH:
- AddCmd
+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/props/P_TARGET_AREA b/doc/props/P_TARGET_AREA
index 9d2cec9..614320f 100644
--- a/doc/props/P_TARGET_AREA
+++ b/doc/props/P_TARGET_AREA
@@ -1,75 +1,95 @@
+
P_TARGET_AREA
+*************
-NAME:
- P_TARGET_AREA "target_area"
-DEFINIERT IN:
- <combat.h>
+NAME
+====
-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.
+ P_TARGET_AREA "target_area"
-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.
+DEFINIERT IN
+============
-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");
+ <combat.h>
- AddExit("unten", RAEUME("lichtung"));
- SetProp(P_TARGET_AREA, RAEUME("lichtung")); // Lichtung beschiessbar
- SetProp(P_SHOOTING_AREA, 15); // 15 Entfernung
- }
+BESCHREIBUNG
+============
- // #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
+ 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.
- 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"}));
+BEMERKUNGEN
+===========
- SetProp(P_SHOOTING_AREA, 8); // weiter als 8 sollte man schiessen
+ 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.
- 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");
- // ...
+ Idealerweise sollte in mit P_TARGET_AREA angegebenen Raeumen auch
+ P_NEVER_CLEAN gesetzt sein.
- 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
+BEISPIELE
+=========
-29.Jul 2014 Gloinson
\ No newline at end of file
+ // #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/props/P_TEAM b/doc/props/P_TEAM
index f03109d..4f853e8 100644
--- a/doc/props/P_TEAM
+++ b/doc/props/P_TEAM
@@ -1,24 +1,39 @@
-NAME:
- P_TEAM "team"
-DEFINIERT IN:
- /sys/living/team.h
+P_TEAM
+******
-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
+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/props/P_TEAM_ASSOC_MEMBERS b/doc/props/P_TEAM_ASSOC_MEMBERS
index c4f95b8..b57a276 100644
--- a/doc/props/P_TEAM_ASSOC_MEMBERS
+++ b/doc/props/P_TEAM_ASSOC_MEMBERS
@@ -1,30 +1,48 @@
-NAME:
- P_TEAM_ASSOC_MEMBERS "team_assoc_members"
-DEFINIERT IN:
- /sys/living/team.h
+P_TEAM_ASSOC_MEMBERS
+********************
-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.
+NAME
+====
-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
+ 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/props/P_TEAM_ATTACK_CMD b/doc/props/P_TEAM_ATTACK_CMD
index 3f77349..b7993e7 100644
--- a/doc/props/P_TEAM_ATTACK_CMD
+++ b/doc/props/P_TEAM_ATTACK_CMD
@@ -1,24 +1,39 @@
-NAME:
- P_TEAM_ATTACK_CMD "team_attack_cmd"
-DEFINIERT IN:
- /sys/living/team.h
+P_TEAM_ATTACK_CMD
+*****************
-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
+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/props/P_TEAM_AUTOFOLLOW b/doc/props/P_TEAM_AUTOFOLLOW
index 45be50f..0e8c45f 100644
--- a/doc/props/P_TEAM_AUTOFOLLOW
+++ b/doc/props/P_TEAM_AUTOFOLLOW
@@ -1,24 +1,39 @@
-NAME:
- P_TEAM_AUTOFOLLOW "team_autofollow"
-DEFINIERT IN:
- /sys/living/team.h
+P_TEAM_AUTOFOLLOW
+*****************
-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
+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/props/P_TEAM_COLORS b/doc/props/P_TEAM_COLORS
index d23815d..a855035 100644
--- a/doc/props/P_TEAM_COLORS
+++ b/doc/props/P_TEAM_COLORS
@@ -1,25 +1,40 @@
-NAME:
- P_TEAM_COLORS "team_colors"
-DEFINIERT IN:
- /sys/living/team.h
+P_TEAM_COLORS
+*************
-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
+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/props/P_TEAM_LEADER b/doc/props/P_TEAM_LEADER
index a123c37..b4927f3 100644
--- a/doc/props/P_TEAM_LEADER
+++ b/doc/props/P_TEAM_LEADER
@@ -1,24 +1,39 @@
-NAME:
- P_TEAM_LEADER "team_leader"
-DEFINIERT IN:
- /sys/living/team.h
+P_TEAM_LEADER
+*************
-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
+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/props/P_TEAM_NEWMEMBER b/doc/props/P_TEAM_NEWMEMBER
index f506c5b..da89b70 100644
--- a/doc/props/P_TEAM_NEWMEMBER
+++ b/doc/props/P_TEAM_NEWMEMBER
@@ -1,25 +1,40 @@
-NAME:
- P_TEAM_NEWMEMBER "potential_team_member"
-DEFINIERT IN:
- /sys/living/team.h
+P_TEAM_NEWMEMBER
+****************
-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
+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/props/P_TEAM_WANTED_ROW b/doc/props/P_TEAM_WANTED_ROW
index 7cd3c36..ba94af4 100644
--- a/doc/props/P_TEAM_WANTED_ROW
+++ b/doc/props/P_TEAM_WANTED_ROW
@@ -1,24 +1,39 @@
-NAME:
- P_TEAM_WANTED_ROW "team_wanted_row"
-DEFINIERT IN:
- /sys/living/team.h
+P_TEAM_WANTED_ROW
+*****************
-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
+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/props/P_TEAM_WIMPY_ROW b/doc/props/P_TEAM_WIMPY_ROW
index a832255..90bfacb 100644
--- a/doc/props/P_TEAM_WIMPY_ROW
+++ b/doc/props/P_TEAM_WIMPY_ROW
@@ -1,28 +1,46 @@
-NAME:
- P_TEAM_WIMPY_ROW "team_wimpy_row"
-DEFINIERT IN:
- /sys/living/team.h
+P_TEAM_WIMPY_ROW
+****************
-BESCHREIBUNG:
- Fluchtreihe des Spielers, von 1 bis MAX_TEAMROWS.
-BEMERKUNG:
- Wenn die Fluchtreihe <=1 ist, ist die Flucht in eine hintere Reihe
- deaktiviert.
+NAME
+====
-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
+ 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/props/P_TELNET_RTTIME b/doc/props/P_TELNET_RTTIME
index fc30011..b781bea 100644
--- a/doc/props/P_TELNET_RTTIME
+++ b/doc/props/P_TELNET_RTTIME
@@ -1,25 +1,43 @@
-NAME:
- P_TELNET_RTTIME "p_lib_telnet_rttime"
-DEFINIERT IN:
- /secure/telnetneg.h
+P_TELNET_RTTIME
+***************
-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.
+NAME
+====
- Die Prop kann nicht gesetzt werden bzw. es hat keinen Effekt.
+ P_TELNET_RTTIME "p_lib_telnet_rttime"
-SIEHE AUCH:
- P_TTY_COLS, P_TTY_ROWS, P_TTY_SHOW, P_TTY, P_TTY_TYPE
-LETZTE AeNDERUNG:
- 03.02.2013, Zesstra
+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/props/P_TESTPLAYER b/doc/props/P_TESTPLAYER
index 6f64ade..bf0c765 100644
--- a/doc/props/P_TESTPLAYER
+++ b/doc/props/P_TESTPLAYER
@@ -1,29 +1,48 @@
-NAME:
- P_TESTPLAYER "testplayer"
-DEFINIERT IN:
- /sys/player/base.h
+P_TESTPLAYER
+************
-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'.
+NAME
+====
-BEMERKUNGEN:
- P_TESTPLAYER kann nur per SetProp() gesetzt werden und das auch nur ein
- Mal! Geloescht werden kann das Flag nur von EM+.
+ P_TESTPLAYER "testplayer"
-ZULETZT GEAeNDERT:
+
+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/props/P_TIMED_ATTR_MOD b/doc/props/P_TIMED_ATTR_MOD
index 1175c50..fa7db3f 100644
--- a/doc/props/P_TIMED_ATTR_MOD
+++ b/doc/props/P_TIMED_ATTR_MOD
@@ -1,59 +1,78 @@
-NAME:
- P_TIMED_ATTR_MOD "timed_attr_mod"
-DEFINIERT IN:
- /sys/living/attributes.h
+P_TIMED_ATTR_MOD
+****************
-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
+NAME
+====
- ({
- ({ Ablaufzeiten }),
- ([ Key : Ablaufobjekt ]),
- ([ Key : ([ Mapping mit den Modifikatoren ]);
- Ablaufzeit ; Ablaufobjekt ; Nachrichtenempfaenger
- ])
- })
+ P_TIMED_ATTR_MOD "timed_attr_mod"
- 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.
+DEFINIERT IN
+============
- 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).
+ /sys/living/attributes.h
- 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.
+BESCHREIBUNG
+============
- ACHTUNG: Bitte nur die bereitgestellten Methoden zur Manipulation
- benutzen! Setzen als Property hat keinen Effekt.
+ 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.
-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
-----------------------------------------------------------------------------
+ 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/props/P_TIMEZONE b/doc/props/P_TIMEZONE
index 8243d07..7e4ce7d 100644
--- a/doc/props/P_TIMEZONE
+++ b/doc/props/P_TIMEZONE
@@ -1,10 +1,23 @@
-NAME:
- P_TIMEZONE "timezone"
-DEFINIERT IN:
- /sys/player/base.h
+P_TIMEZONE
+**********
-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.
+
+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/props/P_TITLE b/doc/props/P_TITLE
index 49afd57..555e26a 100644
--- a/doc/props/P_TITLE
+++ b/doc/props/P_TITLE
@@ -1,8 +1,21 @@
-NAME:
- P_TITLE "title"
-DEFINIERT IN:
- /sys/player/description.h
+P_TITLE
+*******
-BESCHREIBUNG:
- Titel des Spielers. Erscheint hinter dem Namen in Kurz/Langbeschreibung.
+
+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/props/P_TOO_HEAVY_MSG b/doc/props/P_TOO_HEAVY_MSG
index 27ef315..c2a40ea 100644
--- a/doc/props/P_TOO_HEAVY_MSG
+++ b/doc/props/P_TOO_HEAVY_MSG
@@ -1,31 +1,50 @@
-NAME:
- P_TOO_HEAVY_MSG "too_heavy_msg"
-DEFINIERT IN:
- /sys/thing/moving.h
+P_TOO_HEAVY_MSG
+***************
-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.");
+NAME
+====
-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
+ 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/props/P_TOO_MANY_MSG b/doc/props/P_TOO_MANY_MSG
index e23ce32..fd1ffe9 100644
--- a/doc/props/P_TOO_MANY_MSG
+++ b/doc/props/P_TOO_MANY_MSG
@@ -1,31 +1,50 @@
-NAME:
- P_TOO_MANY_MSG "too_many_msg"
-DEFINIERT IN:
- /sys/thing/moving.h
+P_TOO_MANY_MSG
+**************
-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.");
+NAME
+====
-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
+ 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/props/P_TOTAL_AC b/doc/props/P_TOTAL_AC
index 222cffa..baa9cf9 100644
--- a/doc/props/P_TOTAL_AC
+++ b/doc/props/P_TOTAL_AC
@@ -1,23 +1,42 @@
-NAME:
- P_TOTAL_AC "total_ac"
-DEFINIERT IN:
- /sys/living/combat.h
+P_TOTAL_AC
+**********
-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.
+NAME
+====
-SIEHE AUCH:
- P_AC
+ 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/props/P_TOTAL_LIGHT b/doc/props/P_TOTAL_LIGHT
index 41006d2..f4f0083 100644
--- a/doc/props/P_TOTAL_LIGHT
+++ b/doc/props/P_TOTAL_LIGHT
@@ -1,23 +1,42 @@
-NAME:
- P_TOTAL_LIGHT "total_light"
-DEFINIERT IN:
- /sys/properties.h
+P_TOTAL_LIGHT
+*************
-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!
+NAME
+====
- Ein direktes setzen dieser Property ist NICHT moeglich, hierzu bitte
- P_LIGHT benutzen!
+ P_TOTAL_LIGHT "total_light"
-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()
+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/props/P_TOTAL_OBJECTS b/doc/props/P_TOTAL_OBJECTS
index 5f01567..4e2d009 100644
--- a/doc/props/P_TOTAL_OBJECTS
+++ b/doc/props/P_TOTAL_OBJECTS
@@ -1,16 +1,32 @@
-NAME:
- P_TOTAL_OBJECTS "total_objects"
-DEFINIERT IN:
- /sys/container.h
+P_TOTAL_OBJECTS
+***************
-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
+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/props/P_TOTAL_WC b/doc/props/P_TOTAL_WC
index 35ef4a9..19349f0 100644
--- a/doc/props/P_TOTAL_WC
+++ b/doc/props/P_TOTAL_WC
@@ -1,27 +1,45 @@
-NAME:
- P_TOTAL_WC "total_wc"
-DEFINIERT IN:
- /sys/properties.h
+P_TOTAL_WC
+**********
-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.
+NAME
+====
-SIEHE AUCH:
- P_HANDS, P_WC, P_XP
+ 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/props/P_TOTAL_WEIGHT b/doc/props/P_TOTAL_WEIGHT
index 2b62db1..bdb72f6 100644
--- a/doc/props/P_TOTAL_WEIGHT
+++ b/doc/props/P_TOTAL_WEIGHT
@@ -1,8 +1,21 @@
-NAME:
- P_TOTAL_WEIGHT "total_weight"
-DEFINIERT IN:
- /sys/thing/restrictions.h
+P_TOTAL_WEIGHT
+**************
-BESCHREIBUNG:
- Gewicht incl. Inhalt in Gramm. P_WEIGHT_PERCENT wird beruecksichtigt.
+
+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/props/P_TOUCH_DETAILS b/doc/props/P_TOUCH_DETAILS
index d0670f6..f4345db 100644
--- a/doc/props/P_TOUCH_DETAILS
+++ b/doc/props/P_TOUCH_DETAILS
@@ -1,24 +1,43 @@
-NAME:
- P_TOUCH_DETAILS "touch_details"
-DEFINIERT IN:
- /sys/thing/description.h
+P_TOUCH_DETAILS
+***************
-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.
+NAME
+====
-SIEHE AUCH:
- Setzen: AddTouchDetail()
- Loeschen: RemoveTouchDetail()
- Aehnlich: AddDetail(), P_DETAILS
- Sonstiges: GetDetail(), break_string()
+ P_TOUCH_DETAILS "touch_details"
-27. Jan 2013 Gloinson
\ No newline at end of file
+
+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/props/P_TPORT_COST_IN b/doc/props/P_TPORT_COST_IN
index d15e948..f2e51a9 100644
--- a/doc/props/P_TPORT_COST_IN
+++ b/doc/props/P_TPORT_COST_IN
@@ -1,9 +1,22 @@
-NAME:
- P_TPORT_COST_IN "tport_cost_in"
-DEFINIERT IN:
- /sys/properties.h
+P_TPORT_COST_IN
+***************
-BESCHREIBUNG:
- In einem Raum mit Sehertor: Kostenanteil, um sich in den Raum zu
- teleportieren
+
+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/props/P_TPORT_COST_OUT b/doc/props/P_TPORT_COST_OUT
index 369a35d..c97c752 100644
--- a/doc/props/P_TPORT_COST_OUT
+++ b/doc/props/P_TPORT_COST_OUT
@@ -1,9 +1,22 @@
-NAME:
- P_TPORT_COST_OUT "tport_cost_out"
-DEFINIERT IN:
- /sys/properties.h
+P_TPORT_COST_OUT
+****************
-BESCHREIBUNG:
- In einem Raum mit Sehertor: Kostenanteil, sich aus dem Raum heraus
- zu teleportieren
+
+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/props/P_TRANK_FINDEN b/doc/props/P_TRANK_FINDEN
index 8db2365..a3e270d 100644
--- a/doc/props/P_TRANK_FINDEN
+++ b/doc/props/P_TRANK_FINDEN
@@ -1,9 +1,22 @@
-NAME:
- P_TRANK_FINDEN "trank_finden"
-DEFINIERT IN:
- /sys/player/potion.h
+P_TRANK_FINDEN
+**************
-BESCHREIBUNG:
- Wenn die Property auf 1 steht kann immer ein Zaubertrank gefunden
- werden, auch wenn er nicht in der Liste des Spielers steht.
+
+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/props/P_TRANSPARENT b/doc/props/P_TRANSPARENT
index a081b00..56c0558 100644
--- a/doc/props/P_TRANSPARENT
+++ b/doc/props/P_TRANSPARENT
@@ -1,29 +1,46 @@
+
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.
+NAME
+====
- 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.
+ P_TRANSPARENT "transparent"
-BEISPIEL:
- SetProp(P_TRANSPARENT,1); -> normale Meldung
- SetProp(P_TRANSPARENT,"Vom Ruecken des Pferdes aus siehst Du:\n");
+DEFINIERT IN
+============
- Diese Meldung ist natuerlich nur dann sinnvoll, wenn es sich
- auch tatsaechlich um ein Pferd handelt :-)
+ /sys/container.h
-SIEHE AUCH:
- int_long()
-----------------------------------------------------------------------------
+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/props/P_TRAVEL_CMDS b/doc/props/P_TRAVEL_CMDS
index 32f6f65..3f9b0d5 100644
--- a/doc/props/P_TRAVEL_CMDS
+++ b/doc/props/P_TRAVEL_CMDS
@@ -1,38 +1,62 @@
-NAME:
- P_TRAVEL_CMDS "travel_cmds"
-DEFINIERT IN:
- /sys/transport.h
+P_TRAVEL_CMDS
+*************
-BESCHREIBUNG:
- Ein Array mit Befehlen, die zum Verlassen UND Betreten des Trans-
- porters fuehren.
-BEISPIEL:
- void create()
- {
- ::create();
+NAME
+====
- SetProp(P_TRAVEL_CMDS,({ "steig","steige" }) );
+ P_TRAVEL_CMDS "travel_cmds"
- }
- Als Parameter werden hier ausschliesslich 'auf,in' und 'von,aus'
- verarbeitet.
+DEFINIERT IN
+============
- steige auf|in <xxx> fuehrt also zum Betreten des Transporters,
- steige von|aus <xxx> dagegen fuehrt zum Verlassen desselben.
+ /sys/transport.h
-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.
+BESCHREIBUNG
+============
-SIEHE AUCH:
- P_LEAVEFAIL, P_ENTERFAIL, P_ENTERCMDS, P_LEAVECMDS, transporter,
+ Ein Array mit Befehlen, die zum Verlassen UND Betreten des Trans-
+ porters fuehren.
-LETZTER AENDERUNG:
- Don, 24.01.2002, 10:15:07h von Tilly
-
\ No newline at end of file
+
+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/props/P_TRAVEL_INFO b/doc/props/P_TRAVEL_INFO
index b3a502e..720e9ec 100644
--- a/doc/props/P_TRAVEL_INFO
+++ b/doc/props/P_TRAVEL_INFO
@@ -1,31 +1,53 @@
-NAME:
- P_TRAVEL_INFO "travel_info"
-DEFINIERT IN:
- /sys/transport.h
+P_TRAVEL_INFO
+*************
-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.
+NAME
+====
- [1] Das gewuenschte Transportmittel (object) falls
- gewaehlt. Ansonsten 0.
+ P_TRAVEL_INFO "travel_info"
- [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.
+DEFINIERT IN
+============
-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!
+ /sys/transport.h
-SIEHE AUCH:
- /std/transport.c, /std/player/travel.c, reise
-LETZTER AENDERUNG:
- Don, 24.01.2002, 10:15:07h von Tilly
+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/props/P_TRAY b/doc/props/P_TRAY
index 34c9d90..0c394d4 100644
--- a/doc/props/P_TRAY
+++ b/doc/props/P_TRAY
@@ -1,8 +1,21 @@
-NAME:
- P_TRAY "tray"
-DEFINIERT IN:
- /sys/properties.h
+P_TRAY
+******
-BESCHREIBUNG:
- *** KEINE BESCHREIBUNG VORHANDEN ***
+
+NAME
+====
+
+ P_TRAY "tray"
+
+
+DEFINIERT IN
+============
+
+ /sys/properties.h
+
+
+BESCHREIBUNG
+============
+
+ *** KEINE BESCHREIBUNG VORHANDEN ***
diff --git a/doc/props/P_TTY b/doc/props/P_TTY
index 9e4aded..87841fd 100644
--- a/doc/props/P_TTY
+++ b/doc/props/P_TTY
@@ -1,28 +1,45 @@
-NAME:
- P_TTY "tty"
-DEFINIERT IN:
- /secure/telnetneg.h
+P_TTY
+*****
-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!
+NAME
+====
- Die Attribute fett, unterstrichen, blinkend und invers koennen auch
- schon von vt100-Terminals dargestellt werden. Aber nicht ueberall
- sind alle Attribute/Farben implementiert.
+ P_TTY "tty"
- 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!
+DEFINIERT IN
+============
- 3) Sparsam benutzen! Beser noch: nur im Notfall!
+ /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/props/P_TTY_COLS b/doc/props/P_TTY_COLS
index 1716a33..8780417 100644
--- a/doc/props/P_TTY_COLS
+++ b/doc/props/P_TTY_COLS
@@ -1,22 +1,40 @@
-NAME:
- P_TTY_COLS "tty_cols"
-DEFINIERT IN:
- /secure/telnetneg.h
+P_TTY_COLS
+**********
-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.
+NAME
+====
-SIEHE AUCH:
- P_TTY_ROWS, P_TTY_TYPE, P_TTY_SHOW
+ P_TTY_COLS "tty_cols"
-LETZTE AeNDERUNG:
- Sat, 06.02.1999, 14:00:00 von Paracelsus
+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/props/P_TTY_ROWS b/doc/props/P_TTY_ROWS
index 1294d9b..7289109 100644
--- a/doc/props/P_TTY_ROWS
+++ b/doc/props/P_TTY_ROWS
@@ -1,22 +1,40 @@
-NAME:
- P_TTY_ROWS "tty_rows"
-DEFINIERT IN:
- /secure/telnetneg.h
+P_TTY_ROWS
+**********
-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.
+NAME
+====
-SIEHE AUCH:
- P_TTY_COLS, P_TTY_TYPE, P_TTY_SHOW
+ P_TTY_ROWS "tty_rows"
-LETZTE AeNDERUNG:
- Sat, 06.02.1999, 14:00:00 von Paracelsus
+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/props/P_TTY_SHOW b/doc/props/P_TTY_SHOW
index f727433..a43076f 100644
--- a/doc/props/P_TTY_SHOW
+++ b/doc/props/P_TTY_SHOW
@@ -1,17 +1,35 @@
-NAME:
- P_TTY_SHOW "tty_show"
-DEFINIERT IN:
- /secure/telnetneg.h
+P_TTY_SHOW
+**********
-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
+NAME
+====
-LETZTE AeNDERUNG:
- Sat, 06.02.1999, 14:00:00 von Paracelsus
+ 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/props/P_TTY_TYPE b/doc/props/P_TTY_TYPE
index 6935b23..5842cb2 100644
--- a/doc/props/P_TTY_TYPE
+++ b/doc/props/P_TTY_TYPE
@@ -1,23 +1,41 @@
-NAME:
- P_TTY_TYPE "tty_type"
-DEFINIERT IN:
- /secure/telnetneg.h
+P_TTY_TYPE
+**********
-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.
+NAME
+====
-SIEHE AUCH:
- P_TTY_COLS, P_TTY_ROWS, P_TTY_SHOW
+ P_TTY_TYPE "tty_type"
-LETZTE AeNDERUNG:
- Sat, 06.02.1999, 14:00:00 von Paracelsus
+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/props/P_UNIT_DECAY_FLAGS b/doc/props/P_UNIT_DECAY_FLAGS
index f924ff7..25a5ed1 100644
--- a/doc/props/P_UNIT_DECAY_FLAGS
+++ b/doc/props/P_UNIT_DECAY_FLAGS
@@ -1,70 +1,90 @@
+
P_UNIT_DECAY_FLAGS
+******************
-NAME:
- P_UNIT_DECAY_FLAGS "unit_decay_flags"
-DEFINIERT IN:
- /sys/unit.h
+NAME
+====
-BESCHREIBUNG:
- Mit dieser Prop kann das Zerfallsverhalten gesteuert werden, entweder
- fuer alle Clones durch Setzen in der Blueprint oder fuer einzelne Clones.
+ P_UNIT_DECAY_FLAGS "unit_decay_flags"
- 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.
+DEFINIERT IN
+============
- 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!
+ /sys/unit.h
- 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 ]) );
+BESCHREIBUNG
+============
-SIEHE AUCH:
- unit
- P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_QUOTA, P_UNIT_DECAY_MIN
- DoDecay, DoDecayMessage
- /std/unit.c
+ 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/props/P_UNIT_DECAY_INTERVAL b/doc/props/P_UNIT_DECAY_INTERVAL
index 93154cd..e0118c3 100644
--- a/doc/props/P_UNIT_DECAY_INTERVAL
+++ b/doc/props/P_UNIT_DECAY_INTERVAL
@@ -1,37 +1,56 @@
+
P_UNIT_DECAY_INTERVAL
+*********************
-NAME:
- P_UNIT_DECAY_INTERVAL "unit_decay_interval"
-DEFINIERT IN:
- /sys/unit.h
+NAME
+====
-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.
+ P_UNIT_DECAY_INTERVAL "unit_decay_interval"
-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:
+DEFINIERT IN
+============
-SIEHE AUCH:
- unit
- P_UNIT_DECAY_QUOTA, P_UNIT_DECAY_FLAGS, P_UNIT_DECAY_MIN
- DoDecay(), DoDecayMessage()
+ /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/props/P_UNIT_DECAY_MIN b/doc/props/P_UNIT_DECAY_MIN
index 79f9c80..b78a735 100644
--- a/doc/props/P_UNIT_DECAY_MIN
+++ b/doc/props/P_UNIT_DECAY_MIN
@@ -1,51 +1,71 @@
+
P_UNIT_DECAY_MIN
+****************
-NAME:
- P_UNIT_DECAY_MIN "unit_decay_min"
-DEFINIERT IN:
- /sys/unit.h
+NAME
+====
-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.
+ P_UNIT_DECAY_MIN "unit_decay_min"
-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);
+DEFINIERT IN
+============
- // 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);
+ /sys/unit.h
-SIEHE AUCH:
- unit
- P_UNIT_DECAY_INTERVAL, P_UNIT_DECAY_FLAGS, P_UNIT_DECAY_QUOTA
- DoDecay, DoDecayMessage
- /std/unit.c
+
+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/props/P_UNIT_DECAY_QUOTA b/doc/props/P_UNIT_DECAY_QUOTA
index 9144564..0b4c9a6 100644
--- a/doc/props/P_UNIT_DECAY_QUOTA
+++ b/doc/props/P_UNIT_DECAY_QUOTA
@@ -1,45 +1,69 @@
+
+P_UNIT_DECAY_QUOTA
+******************
+
+
P_UNIT_DECAY_QUOTA (int)
+========================
-NAME:
- P_UNIT_DECAY_QUOTA "unit_decay_quota"
-DEFINIERT IN:
- /sys/unit.h
+NAME
+====
-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.
+ P_UNIT_DECAY_QUOTA "unit_decay_quota"
- 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.
+DEFINIERT IN
+============
-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.
+ /sys/unit.h
-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
+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/props/P_UNWEAR_MSG b/doc/props/P_UNWEAR_MSG
index 1ee0d80..0b2e89a 100644
--- a/doc/props/P_UNWEAR_MSG
+++ b/doc/props/P_UNWEAR_MSG
@@ -1,56 +1,78 @@
+
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.
+NAME
+====
- Platzhalter fuer Spieler ist @WExxx1, fuer die Waffe @WExxx2 (siehe
- man replace_personal()).
+ P_UNWEAR_MSG "unwear_msg"
- [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." }));
+DEFINIERT IN
+============
- -> beim Ausziehen durch Urk:
- Urk bekommt: Du reisst dir den Mantel vom Leib.
- Der Raum: Urk reisst sich einen Mantel vom Leib.
+ /sys/armour.h
- 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
+BESCHREIBUNG
+============
-LETZTE AeNDERUNG:
-15.02.2009, Zesstra
\ No newline at end of file
+ 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/props/P_UNWIELD_FUNC b/doc/props/P_UNWIELD_FUNC
index da0fa7c..4466ec0 100644
--- a/doc/props/P_UNWIELD_FUNC
+++ b/doc/props/P_UNWIELD_FUNC
@@ -1,19 +1,32 @@
+
P_UNWIELD_FUNC
+**************
-NAME:
- P_UNWIELD_FUNC "unwield_func"
-DEFINIERT IN:
- <weapon.h>
+NAME
+====
-BESCHREIBUNG:
- Falls ein Objekt eine UnwieldFunc() fuer die Waffe definiert, so muss
- dieses Objekt in dieser Property eingetragen werden.
+ P_UNWIELD_FUNC "unwield_func"
- Die Auswertung dieser Property erfolgt in DoUnwield().
-SIEHE AUCH:
- /std/weapon.c, UnwieldFunc()
+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/props/P_UNWIELD_MSG b/doc/props/P_UNWIELD_MSG
index 49a6466..d1d1668 100644
--- a/doc/props/P_UNWIELD_MSG
+++ b/doc/props/P_UNWIELD_MSG
@@ -1,59 +1,77 @@
+
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.
+NAME
+====
- Der erste Eintrag geht an den Spieler, der zweite Eintrag an die
- Umgebung. Zeilenumbrueche werden automatisch gemacht, existierende
- jedoch beruecksichtigt.
+ P_UNWIELD_MSG "unwield_msg"
- 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.]
+DEFINIERT IN
+============
-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." }));
+ /sys/weapon.h
- -> 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."}));
+BESCHREIBUNG
+============
- -> 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.
+ Zweiteiliges Array mit Meldungen, die beim Wegstecken einer
+ Waffe an den Spieler und die Umgebung ausgegeben werden.
-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
+ 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/props/P_UNWIELD_TIME b/doc/props/P_UNWIELD_TIME
index 43128d4..e93a24b 100644
--- a/doc/props/P_UNWIELD_TIME
+++ b/doc/props/P_UNWIELD_TIME
@@ -1,19 +1,33 @@
+
P_UNWIELD_TIME
+**************
-NAME:
- P_UNWIELD_TIME "unwield_time"
-DEFINIERT IN:
- /sys/weapon.h
+NAME
+====
-BESCHREIBUNG:
- Enthaelt den Zeitpunkt zu dem ein Living eine Waffe weggesteckt hat und
- ist im Living gesetzt.
+ P_UNWIELD_TIME "unwield_time"
-SIEHE AUCH:
- Verwandt: P_WEAPON, P_WIELDED, DoUnwield()
- P_LAST_USE
- Sonstiges: P_EQUIP_TIME
- time()
-10.Feb 2005 Gloinson
+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/props/P_USED_HANDS b/doc/props/P_USED_HANDS
index 456d32c..b90bd61 100644
--- a/doc/props/P_USED_HANDS
+++ b/doc/props/P_USED_HANDS
@@ -1,21 +1,39 @@
+
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).
+NAME
+====
-BEMERKUNGEN:
- Keine echte Property. Die Methode /std/living/combat::_query_used_hands
- stellt die Daten zusammen. Nicht setzen!
+ P_USED_HANDS "used_hands"
-SIEHE AUCH:
- P_HANDS, P_HANDS_USED_BY
- P_MAX_HANDS, P_FREE_HANDS
- UseHands, FreeHands
+
+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/props/P_VALID_GUILDS b/doc/props/P_VALID_GUILDS
index 2734ad9..f431e7b 100644
--- a/doc/props/P_VALID_GUILDS
+++ b/doc/props/P_VALID_GUILDS
@@ -1,23 +1,41 @@
-NAME:
- P_VALID_GUILDS "valid_guilds"
-DEFINIERT IN:
- /sys/new_skills.h
+P_VALID_GUILDS
+**************
-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"})
+NAME
+====
-SIEHE AUCH:
- P_GUILD, /obj/gildenmaster.c
+ 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/props/P_VALUE b/doc/props/P_VALUE
index d9b5961..cb48202 100644
--- a/doc/props/P_VALUE
+++ b/doc/props/P_VALUE
@@ -1,26 +1,43 @@
-NAME:
- P_VALUE "value"
-DEFINIERT IN:
- /sys/properties.h
+P_VALUE
+*******
-BESCHREIBUNG:
- - Objekte
- Wert des Objektes in Goldmuenzen. Diesen Wert erhaelt man beim
- Verkauf. Kaufen kostet ein Vielfaches hiervon.
+NAME
+====
- - 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
+ P_VALUE "value"
-------------------------------------------------------------------------------
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
\ No newline at end of file
+
+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/props/P_VALUE_PER_UNIT b/doc/props/P_VALUE_PER_UNIT
index da779c5..3ff1b3c 100644
--- a/doc/props/P_VALUE_PER_UNIT
+++ b/doc/props/P_VALUE_PER_UNIT
@@ -1,14 +1,29 @@
-NAME:
- P_VALUE_PER_UNIT "value_per_unit"
-DEFINIERT IN:
- /sys/properties.h
+P_VALUE_PER_UNIT
+****************
-BESCHREIBUNG:
- Wert in Goldstuecken pro Untereinheit.
-BEMERKUNGEN:
- Deprecated. Bitte SetCoinsPerUnits() (U_CPU) benutzen.
+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/props/P_VARIABLES b/doc/props/P_VARIABLES
index 5e7fb5c..52a979c 100644
--- a/doc/props/P_VARIABLES
+++ b/doc/props/P_VARIABLES
@@ -1,16 +1,28 @@
-NAME:
- P_VARIABLES "variables"
+P_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!
+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/props/P_VISIBLE_GUILD b/doc/props/P_VISIBLE_GUILD
index df267b5..92de8b7 100644
--- a/doc/props/P_VISIBLE_GUILD
+++ b/doc/props/P_VISIBLE_GUILD
@@ -1,25 +1,42 @@
+
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.
+NAME
+====
-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.
+ P_VISIBLE_GUILD "visible_guild"
-SIEHE AUCH:
- P_GUILD, P_DEFAULT_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/props/P_VISIBLE_SUBGUILD_TITLE b/doc/props/P_VISIBLE_SUBGUILD_TITLE
index e398f02..e0e5c83 100644
--- a/doc/props/P_VISIBLE_SUBGUILD_TITLE
+++ b/doc/props/P_VISIBLE_SUBGUILD_TITLE
@@ -1,21 +1,39 @@
+
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.
+NAME
+====
-SIEHE AUCH:
- P_GUILD_TITLE, P_SUBGUILD_TITLE
+ 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/props/P_VISUALBELL b/doc/props/P_VISUALBELL
index 19e8519..8a3d836 100644
--- a/doc/props/P_VISUALBELL
+++ b/doc/props/P_VISUALBELL
@@ -1,37 +1,58 @@
-NAME:
- P_VISUALBELL "visualbell"
-DEFINIERT IN:
- /sys/properties.h
+P_VISUALBELL
+************
-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).
+NAME
+====
-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.
+ P_VISUALBELL "visualbell"
-SIEHE AUCH:
- ton, wecke, erwarte, P_WAITFOR, /std/player/base.c
-----------------------------------------------------------------------------
+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/props/P_VULNERABILITY b/doc/props/P_VULNERABILITY
index 7e1c676..f0e3abb 100644
--- a/doc/props/P_VULNERABILITY
+++ b/doc/props/P_VULNERABILITY
@@ -1,37 +1,62 @@
-NAME:
- P_VULNERABILITY "vulnerability"
-DEFINIERT IN:
- /sys/living/combat.h
+P_VULNERABILITY
+***************
-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.
+NAME
+====
-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
+ P_VULNERABILITY "vulnerability"
-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
+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/props/P_WAITFOR b/doc/props/P_WAITFOR
index a8cf8ee..301838e 100644
--- a/doc/props/P_WAITFOR
+++ b/doc/props/P_WAITFOR
@@ -1,14 +1,30 @@
-NAME:
- P_WAITFOR "waitfor"
-DEFINIERT IN:
- /sys/player/base.h
+P_WAITFOR
+*********
-BESCHREIBUNG:
- Die Erwarte-Liste. Ein Array mit den Namen der Erwarteten.
-SIEHE AUCH:
- erwarte
- P_WAITFOR_REASON, P_WAITFOR_FLAGS
+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/props/P_WAITFOR_FLAGS b/doc/props/P_WAITFOR_FLAGS
index f137dd1..5e616b7 100644
--- a/doc/props/P_WAITFOR_FLAGS
+++ b/doc/props/P_WAITFOR_FLAGS
@@ -1,17 +1,34 @@
+
P_WAITFOR_FLAGS
-NAME:
- P_WAITFOR_FLAGS "waitfor_flags"
+***************
-DEFINIERT IN:
- /sys/player/base.h
-BESCHREIBUNG:
- Ein Int. Bisher bekannte Flags:
-
- 0x01 - "erwarte aus"
+NAME
+====
-SIEHE AUCH:
- erwarte
- P_WAITFOR, P_WAITFOR_REASON
+ 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/props/P_WAITFOR_REASON b/doc/props/P_WAITFOR_REASON
index b19c821..1d997d8 100644
--- a/doc/props/P_WAITFOR_REASON
+++ b/doc/props/P_WAITFOR_REASON
@@ -1,18 +1,35 @@
+
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"])
+NAME
+====
-SIEHE AUCH:
- erwarte (erwarte <wen> wegen <was>)
- P_WAITFOR, P_WAITFOR_FLAGS
+ 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/props/P_WANTS_TO_LEARN b/doc/props/P_WANTS_TO_LEARN
index a1553bd..639ab61 100644
--- a/doc/props/P_WANTS_TO_LEARN
+++ b/doc/props/P_WANTS_TO_LEARN
@@ -1,12 +1,25 @@
-NAME:
- P_WANTS_TO_LEARN "wants_to_learn"
-DEFINIERT IN:
- /sys/player/base.h
+P_WANTS_TO_LEARN
+****************
-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.
+
+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/props/P_WATER b/doc/props/P_WATER
index 6be4fe6..79742c1 100644
--- a/doc/props/P_WATER
+++ b/doc/props/P_WATER
@@ -1,110 +1,130 @@
-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
+P_WATER
+*******
- 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
+NAME
+====
- SetProp(P_WATER, W_HARBOR|W_OCEAN);
+ P_WATER "water"
- schaltet das die Angel sowohl fuer Haefen, als auch fuer offene Meere
- (Ozeane) frei.
- Folgende kombinierte Gewaessertypen sind fuer einfache Angeln
- vordefiniert:
+DEFINIERT IN
+============
- 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
+ /sys/fishing.h
- 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.
+BESCHREIBUNG
+============
- 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.
+ Enthaelt den Gewaessertyp. Kann in Raeumen, Angeln und Wasserbehaeltern
+ verwendet werden. Die verfuegbaren Optionen und Funktionsweisen sind in
+ den nachfolgenden Abschnitten aufgefuehrt.
-SIEHE AUCH:
+ 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.
- Properties: P_FISH
- Methoden: GetAquarium(L)
-------------------------------------------------------------------------------
+
+ 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/props/P_WC b/doc/props/P_WC
index 042de3d..cfa18e4 100644
--- a/doc/props/P_WC
+++ b/doc/props/P_WC
@@ -1,37 +1,56 @@
-NAME:
- P_WC "wc"
-DEFINIERT IN:
- /sys/weapon.h
+P_WC
+****
-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 dem
- Erzmagier fuer Ruestungen, Waffen und Monster!
- 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.
+NAME
+====
-SIEHE AUCH:
- /std/weapon.c, /std/weapon/combat.c
- P_DAMAGED, P_EFFECTIVE_WC, P_WEAPON_TYPE
- Damage()
-----------------------------------------------------------------------------
-02.10.2007, Zesstra
+ 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/props/P_WEAPON b/doc/props/P_WEAPON
index 5b1854c..a7f68b2 100644
--- a/doc/props/P_WEAPON
+++ b/doc/props/P_WEAPON
@@ -1,17 +1,31 @@
+
P_WEAPON
+********
-NAME:
- P_WEAPON "weapon"
-DEFINIERT IN:
- /sys/properties.h
+NAME
+====
-BESCHREIBUNG:
- Momentan gezueckte Waffe. Im Living gesetzt.
+ P_WEAPON "weapon"
-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
+
+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/props/P_WEAPON_TEACHER b/doc/props/P_WEAPON_TEACHER
index 685f9e4..ebeb788 100644
--- a/doc/props/P_WEAPON_TEACHER
+++ b/doc/props/P_WEAPON_TEACHER
@@ -1,18 +1,29 @@
-NAME:
- P_WEAPON_TEACHER "weapon_teacher"
+
+P_WEAPON_TEACHER
+****************
-DEFINIERT IN:
- combat.h
+NAME
+====
-BESCHREIBUNG:
- Diese Property wird in einem Azubi gesetzt (zur Zeit nur fuer die
- Kaempfer-Gilde), der selbst ueber die allgemeinen Waffenskills
- verfuegt.
+ P_WEAPON_TEACHER "weapon_teacher"
- In diese Property wird der Name eines Kaempfergilden-Ausbilders
- eingetragen.
- Unter Anleitung des Ausbilders lernt der Azubi dann etwas schneller
- die allgemeinen Waffenskills.
+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/props/P_WEAPON_TYPE b/doc/props/P_WEAPON_TYPE
index 06f3c0b..d200054 100644
--- a/doc/props/P_WEAPON_TYPE
+++ b/doc/props/P_WEAPON_TYPE
@@ -1,31 +1,41 @@
+
P_WEAPON_TYPE
+*************
-NAME:
- P_WEAPON_TYPE "weapon_type"
-DEFINIERT IN:
- <weapon.h>
+NAME
+====
-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:
+ P_WEAPON_TYPE "weapon_type"
- 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.
+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/props/P_WEAR_FUNC b/doc/props/P_WEAR_FUNC
index edc9bcc..d288187 100644
--- a/doc/props/P_WEAR_FUNC
+++ b/doc/props/P_WEAR_FUNC
@@ -1,24 +1,44 @@
+
P_WEAR_FUNC
+***********
-NAME:
- P_WEAR_FUNC "wear_func"
-DEFINIERT IN:
- <armour.h>
+NAME
+====
-BESCHREIBUNG:
- Falls ein Objekt eine WearFunc() fuer die Ruestung / Kleidung definiert,
- so muss dieses Objekt in dieser Property eingetragen sein.
+ P_WEAR_FUNC "wear_func"
- Die Auswertung dieser Property erfolgt in Laufe eines DoWear() in der
- nicht-oeffentlichen Funktion _check_wear_restrictions()..
-BEISPIELE:
- Siehe das Beispiel zu WearFunc()
+DEFINIERT IN
+============
-SIEHE AUCH:
- armours, clothing, /std/clothing/wear.c, /std/armour/wear.c
- WearFunc(), InformWear()
+ <armour.h>
-LETZTE AeNDERUNG:
-15.02.2009, Zesstra
\ No newline at end of file
+
+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/props/P_WEAR_MSG b/doc/props/P_WEAR_MSG
index 31407fa..69fbf44 100644
--- a/doc/props/P_WEAR_MSG
+++ b/doc/props/P_WEAR_MSG
@@ -1,61 +1,82 @@
+
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.
+NAME
+====
- Platzhalter fuer Spieler ist @WExxx1, fuer die Waffe @WExxx2 (siehe
- man replace_personal()).
+ P_WEAR_MSG "wear_msg"
- [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."}));
+DEFINIERT IN
+============
- -> beim Anziehe durch Urk:
- Urk bekommt: Du stuelpst dir den Helm ueber.
- Der Raum: Urk stuelpt sich einen Helm ueber.
+ /sys/armour.h
- 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.
+BESCHREIBUNG
+============
- 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.
+ 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.
-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
+ Platzhalter fuer Spieler ist @WExxx1, fuer die Waffe @WExxx2 (siehe
+ man replace_personal()).
-LETZTE AeNDERUNG:
-15.02.2009
\ No newline at end of file
+ [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/props/P_WEIGHT b/doc/props/P_WEIGHT
index 22af5f0..4c37e46 100644
--- a/doc/props/P_WEIGHT
+++ b/doc/props/P_WEIGHT
@@ -1,26 +1,43 @@
-NAME:
- P_WEIGHT "weight"
-DEFINIERT IN:
- /sys/thing/restrictions.h
+P_WEIGHT
+********
-BESCHREIBUNG:
- - Objekte
- Das Gewicht eines Objetes in Gramm.
+NAME
+====
- - 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
+ P_WEIGHT "weight"
-------------------------------------------------------------------------------
-Last modified: Thu Oct 28 12:15:00 2010 by Caldra
\ No newline at end of file
+
+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/props/P_WEIGHT_PERCENT b/doc/props/P_WEIGHT_PERCENT
index 7bb1ad3..a4d0506 100644
--- a/doc/props/P_WEIGHT_PERCENT
+++ b/doc/props/P_WEIGHT_PERCENT
@@ -1,25 +1,47 @@
-NAME:
- P_WEIGHT_PERCENT "weight_percent"
-DEFINIERT IN:
- /sys/properties.h
+P_WEIGHT_PERCENT
+****************
-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.
+NAME
+====
- Container die hier einen Wert ueber dem des Postpakets haben, sollten
- auch schwer zu erreichen sein. Auf jeden Fall mit dem Regionsmagier
- besprechen!
+ P_WEIGHT_PERCENT "weight_percent"
-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
+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/props/P_WEIGHT_PER_UNIT b/doc/props/P_WEIGHT_PER_UNIT
index 2796b7b..c777b65 100644
--- a/doc/props/P_WEIGHT_PER_UNIT
+++ b/doc/props/P_WEIGHT_PER_UNIT
@@ -1,13 +1,29 @@
-NAME:
- P_WEIGHT_PER_UNIT "weight_per_unit"
-DEFINIERT IN:
- /sys/properties.h
+P_WEIGHT_PER_UNIT
+*****************
-BESCHREIBUNG:
- Gewicht in Gramm pro Untereinheit.
-BEMERKUNGEN:
- Deprecated. Bitte SetGramsPerUnits() (U_GPU) benutzen.
+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/props/P_WIELDED b/doc/props/P_WIELDED
index bce8580..26bcff7 100644
--- a/doc/props/P_WIELDED
+++ b/doc/props/P_WIELDED
@@ -1,21 +1,37 @@
+
P_WIELDED
+*********
-NAME:
- P_WIELDED "wielded"
-DEFINIERT IN:
- <weapon.h>
+NAME
+====
-BESCHREIBUNG:
- Ist diese Property gesetzt, dann ist die Waffe gerade gezueckt. Der
- Traeger ist in der Property vermerkt.
+ P_WIELDED "wielded"
-BEMERKUNGEN:
- Diese Property laesst sich nur abfragen!
-SIEHE AUCH:
- /std/weapon.c
- P_WEAPON
+DEFINIERT IN
+============
-----------------------------------------------------------------------------
-Last modified: 2015-Jul-11, Arathorn
+ <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/props/P_WIELD_FUNC b/doc/props/P_WIELD_FUNC
index fac481b..fbe49a7 100644
--- a/doc/props/P_WIELD_FUNC
+++ b/doc/props/P_WIELD_FUNC
@@ -1,22 +1,38 @@
+
P_WIELD_FUNC
+************
-NAME:
- P_WIELD_FUNC "wield_func"
-DEFINIERT IN:
- <weapon.h>
+NAME
+====
-BESCHREIBUNG:
- Falls ein Objekt eine WieldFunc() fuer die Waffe definiert, so muss
- dieses Objekt in dieser Property eingetragen werden.
+ P_WIELD_FUNC "wield_func"
- Die Auswertung dieser Property erfolgt in wield_me().
-BEISPIELE:
- Siehe das Beispiel zu WieldFunc()
+DEFINIERT IN
+============
-SIEHE AUCH:
- /std/weapon.c, WieldFunc()
+ <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/props/P_WIELD_MSG b/doc/props/P_WIELD_MSG
index 357a304..fa9dafc 100644
--- a/doc/props/P_WIELD_MSG
+++ b/doc/props/P_WIELD_MSG
@@ -1,57 +1,74 @@
+
P_WIELD_MSG
-NAME:
- P_WIELD_MSG "wield_msg"
+***********
-DEFINIERT IN:
- /sys/weapon.h
-BESCHREIBUNG:
+NAME
+====
- 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.
+ P_WIELD_MSG "wield_msg"
- 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.]
+DEFINIERT IN
+============
-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." }));
+ /sys/weapon.h
- -> 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 ..."}));
+BESCHREIBUNG
+============
- -> 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 ...
+ 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.
-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
+ 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/props/P_WIMPY b/doc/props/P_WIMPY
index 97633fa..d0ba078 100644
--- a/doc/props/P_WIMPY
+++ b/doc/props/P_WIMPY
@@ -1,15 +1,30 @@
-NAME:
- P_WIMPY "wimpy"
-DEFINIERT IN:
- /sys/properties.h
+P_WIMPY
+*******
-BESCHREIBUNG:
- Numerischer Wert. Das Lebewesen flieht, wenn die Lebenspunkte
- unter diesen Wert sinken.
-SIEHE AUCH:
- P_WIMPY_DIRECTION
+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/props/P_WIMPY_DIRECTION b/doc/props/P_WIMPY_DIRECTION
index 57d2f01..11bedeb 100644
--- a/doc/props/P_WIMPY_DIRECTION
+++ b/doc/props/P_WIMPY_DIRECTION
@@ -1,22 +1,40 @@
-NAME:
- P_WIMPY_DIRECTION "wimpy_dir"
-DEFINIERT IN:
- /sys/properties.h
+P_WIMPY_DIRECTION
+*****************
-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!>).
+NAME
+====
- Ausgefuehrt wird die Fluchtrichtung per command(), wenn die LP des
- Lebewesens unter die mit <vorsicht> angegebe LP-Grenze sinkt.
+ P_WIMPY_DIRECTION "wimpy_dir"
-SIEHE AUCH:
- P_WIMPY
-----------------------------------------------------------------------------
+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/props/P_WIZ_DEBUG b/doc/props/P_WIZ_DEBUG
index cf7ac21..0bea2ad 100644
--- a/doc/props/P_WIZ_DEBUG
+++ b/doc/props/P_WIZ_DEBUG
@@ -1,20 +1,37 @@
-NAME:
- P_WIZ_DEBUG "std_p_wizdebug"
-DEFINIERT IN:
- /sys/player/comm.h
+P_WIZ_DEBUG
+***********
-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
+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/props/P_WORN b/doc/props/P_WORN
index 7afd03e..999ab76 100644
--- a/doc/props/P_WORN
+++ b/doc/props/P_WORN
@@ -1,40 +1,63 @@
+
P_WORN
+******
-NAME:
- P_WORN "worn"
-DEFINIERT IN:
- <armour.h>
+NAME
+====
-BESCHREIBUNG:
- Mittels dieser Property laesst sich ermitteln, ob eine Ruestung bzw.
- Kleidung derzeit getragen wird und wenn ja, von wem.
+ P_WORN "worn"
- Entweder enthaelt die Property den Wert 0, oder sie enthaelt den
- Traeger der Ruestung / Kleidung (als Objekt).
-BEMERKUNGEN:
- Diese Property laesst sich nur abfragen!
+DEFINIERT IN
+============
-BEISPIELE:
- Eine DefendFunc() koennte dem Traeger der Ruestung wie folgt etwas
- mitteilen:
+ <armour.h>
- // 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;
+
+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
\ No newline at end of file
+SIEHE AUCH
+==========
+
+ clothing, /std/clothing.c, armour, /std/armour.c
+
+
+LETZTE AeNDERUNG
+================
+
+15.02.2009, Zesstra
diff --git a/doc/props/P_XP b/doc/props/P_XP
index 097ec65..649f4e0 100644
--- a/doc/props/P_XP
+++ b/doc/props/P_XP
@@ -1,59 +1,81 @@
-NAME:
- P_XP "xp"
-DEFINIERT IN:
- /sys/living/life.h
+P_XP
+****
-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).
+NAME
+====
- 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.
+ P_XP "xp"
-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);
- }
+DEFINIERT IN
+============
- Beim Toeten gibt es nun 25.000.000/100 = 250.000 Erfahrungspunkte.
- Damit wird der NPC sogar automatisch fuer die Vergabe von
- Erstkillstufenpunkten vorgesehen.
+ /sys/living/life.h
- 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".
+BESCHREIBUNG
+============
-SIEHE AUCH:
- Funktionen: AddExp(), do_damage()
- Verwandt: P_NO_XP, P_LAST_XP
- Sonstiges: P_NO_SCORE, create_default_npc()
- P_TOTAL_WC
+ 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.
-14.Feb 2007 Gloinson
\ No newline at end of file
+ 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/props/P_X_ATTR_MOD b/doc/props/P_X_ATTR_MOD
index c6a8bda..14ab9a4 100644
--- a/doc/props/P_X_ATTR_MOD
+++ b/doc/props/P_X_ATTR_MOD
@@ -1,46 +1,68 @@
-NAME:
- P_X_ATTR_MOD "extern_attributes_modifier"
-DEFINIERT IN:
- /sys/living/attributes.h
+P_X_ATTR_MOD
+************
-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.
+NAME
+====
- 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 "extern_attributes_modifier"
- 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.
+DEFINIERT IN
+============
-BEISPIEL:
- // Dem Lebewesen, das das Objekt bei sich hat, wird 2 von A_INT abgezogen
- SetProp(P_X_ATTR_MOD,([A_INT:-2]));
+ /sys/living/attributes.h
- // 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
+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/props/P_X_HEALTH_MOD b/doc/props/P_X_HEALTH_MOD
index d78d2bf..69aafab 100644
--- a/doc/props/P_X_HEALTH_MOD
+++ b/doc/props/P_X_HEALTH_MOD
@@ -1,36 +1,60 @@
-NAME:
- P_X_HEALTH_MOD "extern_health_modifier"
-DEFINIERT IN:
- /sys/living/attributes.h
+P_X_HEALTH_MOD
+**************
-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.
+NAME
+====
- Bei Ruestungen/Waffen, die diese Wirkung entfalten sollen, verwendet
- man besser P_M_HEALTH_MOD.
+ P_X_HEALTH_MOD "extern_health_modifier"
-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,([]);
+DEFINIERT IN
+============
-SIEHE AUCH:
- P_M_HEALTH_MOD, P_X_ATTR_MOD, P_M_ATTR_MOD, balance
+ /sys/living/attributes.h
-LETZTE AeNDERUNG:
- Sat, 06.02.1999, 14:00:00 von Paracelsus
+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/props/P_ZAP_MSG b/doc/props/P_ZAP_MSG
index fbabff4..6f9c7ce 100644
--- a/doc/props/P_ZAP_MSG
+++ b/doc/props/P_ZAP_MSG
@@ -1,28 +1,41 @@
+
P_ZAP_MSG
+*********
-NAME:
- P_ZAP_MSG "zap_msg"
-DEFINIERT IN:
- /sys/properties.h
+NAME
+====
-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.
+ P_ZAP_MSG "zap_msg"
- 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.
+DEFINIERT IN
+============
-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
+ /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/props/U_REQ b/doc/props/U_REQ
index cb395db..1594c4f 100644
--- a/doc/props/U_REQ
+++ b/doc/props/U_REQ
@@ -1,63 +1,83 @@
-NAME:
- U_REQ "u_req"
-DEFINIERT IN:
- /sys/unit.h
+U_REQ
+*****
-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.
+NAME
+====
- 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().)
+ U_REQ "u_req"
- Ebenso wird U_REQ bei der Vereinigung mit einem anderen (gleichen)
- Objekt auf P_AMOUNT des vereinigten Objektes gesetzt.
+
+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.
+====
+
+ 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.)
+ 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.)
- # 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.
+ 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:
+ZULETZT GEAeNDERT
+=================
+
16.01.2015, Zesstra
-
diff --git a/doc/props/gildenprops/P_GLOVE_FINGERLESS b/doc/props/gildenprops/P_GLOVE_FINGERLESS
index 64faec6..0485c9a 100644
--- a/doc/props/gildenprops/P_GLOVE_FINGERLESS
+++ b/doc/props/gildenprops/P_GLOVE_FINGERLESS
@@ -1,16 +1,30 @@
+
P_GLOVE_FINGERLESS
+******************
-NAME:
- P_GLOVE_FINGERLESS "fingerfreie_handschuhe"
-DEFINIERT IN:
- /p/katzenkrieger/kkrieger.h
+NAME
+====
-BESCHREIBUNG:
- So gekennzeichnete Handschuhe sind fingerlos und koennen
- waehrend "krallenschlag" getragen werden.
+ P_GLOVE_FINGERLESS "fingerfreie_handschuhe"
-SIEHE AUCH:
- Verwandt: P_ARMOUR_TYPE, AT_GLOVE
-10.Okt 2006 Gloinson
\ No newline at end of file
+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/props/gildenprops/P_Z_AUTOSHIELD b/doc/props/gildenprops/P_Z_AUTOSHIELD
index f69b9ad..994abad 100644
--- a/doc/props/gildenprops/P_Z_AUTOSHIELD
+++ b/doc/props/gildenprops/P_Z_AUTOSHIELD
@@ -1,26 +1,43 @@
+
P_Z_AUTOSHIELD
+**************
-NAME:
- P_Z_AUTOSHIELD "z_autoshield"
-DEFINIERT IN:
- /p/zauberer/wiznpc.h
+NAME
+====
-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".
+ P_Z_AUTOSHIELD "z_autoshield"
-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
+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/props/gildenprops/P_Z_INFO b/doc/props/gildenprops/P_Z_INFO
index d82d38a..654c768 100644
--- a/doc/props/gildenprops/P_Z_INFO
+++ b/doc/props/gildenprops/P_Z_INFO
@@ -1,53 +1,73 @@
+
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.
+NAME
+====
- 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.
+ P_Z_INFO "z_info"
-SIEHE AUCH:
- /p/zauberer/text/wiznpc.doku
+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/props/gildenprops/P_Z_NO_MATERIAL b/doc/props/gildenprops/P_Z_NO_MATERIAL
index 4b040a0..cda514a 100644
--- a/doc/props/gildenprops/P_Z_NO_MATERIAL
+++ b/doc/props/gildenprops/P_Z_NO_MATERIAL
@@ -1,18 +1,34 @@
+
P_Z_NO_MATERIAL
+***************
-NAME:
- P_Z_NO_MATERIAL "npc_braucht_keine_kmp"
-DEFINIERT IN:
- /p/zauberer/zauberer.h
+NAME
+====
-BESCHREIBUNG:
- Setzt man diese Property in einem NPC, so benoetigt er fuer die
- Sprueche der Zauberergilde keine Komponenten.
+ P_Z_NO_MATERIAL "npc_braucht_keine_kmp"
-BEMERKUNGEN:
- NIEMALS diese Property einfach so in einem Spieler setzen.
-SIEHE AUCH:
+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/props/gildenprops/P_Z_NO_NOCONN b/doc/props/gildenprops/P_Z_NO_NOCONN
index 332dd14..6cd0024 100644
--- a/doc/props/gildenprops/P_Z_NO_NOCONN
+++ b/doc/props/gildenprops/P_Z_NO_NOCONN
@@ -1,22 +1,42 @@
+
+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.
+NAME
+====
-SIEHE AUCH:
- /p/zauberer/text/wiznpc.doku, P_Z_INFO
+ 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/props/gildenprops/P_Z_NO_SPELL_SUPPORT b/doc/props/gildenprops/P_Z_NO_SPELL_SUPPORT
index 4a1ab28..74860f6 100644
--- a/doc/props/gildenprops/P_Z_NO_SPELL_SUPPORT
+++ b/doc/props/gildenprops/P_Z_NO_SPELL_SUPPORT
@@ -1,25 +1,41 @@
+
P_Z_NO_SPELL_SUPPORT
+********************
-NAME:
- P_Z_NO_SPELL_SUPPORT "zauberer_ruestung_unterstuetzt_noch_nicht"
-DEFINIERT IN:
- /p/zauberer/zauberer.h
+NAME
+====
-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.
+ P_Z_NO_SPELL_SUPPORT "zauberer_ruestung_unterstuetzt_noch_nicht"
-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:
+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/props/gildenprops/kaempferboni b/doc/props/gildenprops/kaempferboni
index 50e4be5..0d34e98 100644
--- a/doc/props/gildenprops/kaempferboni
+++ b/doc/props/gildenprops/kaempferboni
@@ -1,264 +1,270 @@
+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.
+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:
-
+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.
+ 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:
+ 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
+ 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.
+ 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.)
-
+ 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.
+ 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"
-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.
- 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.
-
+ 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.
+ 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.
+ 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).
-
+ 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"
+ "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.
+ 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.
-
+ 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%.
+ 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.
+ 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.
-
+ 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.
+ 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.
+ 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.
-
+ 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.
+ 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.
-
+ 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.
-
+ 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.
+<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:
-
+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.
+ 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.
+ 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.
+ 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.
+ 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.
+ 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.
-
+ 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.).
+ 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.
+ 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).
+ 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').
+ 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.
+ 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
+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/props/obsolete/P_BALANCED_WEAPON b/doc/props/obsolete/P_BALANCED_WEAPON
index e785f2c..83a2fc4 100644
--- a/doc/props/obsolete/P_BALANCED_WEAPON
+++ b/doc/props/obsolete/P_BALANCED_WEAPON
@@ -1,35 +1,59 @@
-********************* 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
+P_BALANCED_WEAPON
+*****************
-BESCHREIBUNG:
- Die Property gibt an, ob eine Waffe ausbalanciert ist oder nicht.
- Die beiden moeglichen Werte sind logischerweise:
+********************* 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.
+* *******************************************************************
+****
- WP_BALANCED balanciert
- WP_UNBALANCED unbalanciert
- Die WP_* sind ebenfalls in <weapon.h> definiert.
+NAME
+====
-BEISPIELE:
- a) Eine ausbalancierte Waffe ist z.B. ein Kampfstab.
+ P_BALANCED_WEAPON "balanced_weapon"
- SetProp(P_BALANCED_WEAPON,WP_BALANCED);
- b) Eine nicht ausbalancierte Waffe ist z.B. eine Keule.
+DEFINIERT IN
+============
- SetProp(P_BALANCED_WEAPON,WP_UNBALANCED);
+ /sys/weapon.h
-SIEHE AUCH:
- P_TECHNIQUE, /std/weapon/combat.c
-LETZTE AeNDERUNG:
+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/props/obsolete/P_DEFAULT_INFO b/doc/props/obsolete/P_DEFAULT_INFO
index 814928c..9a16169 100644
--- a/doc/props/obsolete/P_DEFAULT_INFO
+++ b/doc/props/obsolete/P_DEFAULT_INFO
@@ -1,28 +1,50 @@
-********************* VERALTETE PROPERTY ******************************
-* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
-***********************************************************************
-NAME:
- P_DEFAULT_INFO "default_info"
+P_DEFAULT_INFO
+**************
-DEFINIERT IN:
- /sys/properties.h
+********************* VERALTETE PROPERTY
+****************************** * Diese Property ist veraltet. Bitte
+nicht mehr in neuem Code nutzen. * **********************************
+*************************************
-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.
+NAME
+====
-BEISPIEL:
- SetProp(P_DEFAULT_INFO,"bohrt gelangweilt in der Nase.\n");
+ P_DEFAULT_INFO "default_info"
-SIEHE AUCH:
- AddInfo
-----------------------------------------------------------------------------
+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/props/obsolete/P_EXTRA_LOOK b/doc/props/obsolete/P_EXTRA_LOOK
deleted file mode 100644
index 3777a25..0000000
--- a/doc/props/obsolete/P_EXTRA_LOOK
+++ /dev/null
@@ -1,35 +0,0 @@
-********************* 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/props/obsolete/P_LAST_KILLER b/doc/props/obsolete/P_LAST_KILLER
index 27eea8f..199a878 100644
--- a/doc/props/obsolete/P_LAST_KILLER
+++ b/doc/props/obsolete/P_LAST_KILLER
@@ -1,20 +1,37 @@
-********************* VERALTETE PROPERTY ******************************
-* Diese Property ist veraltet und wird bald aus der Mudlib entfernt. *
-***********************************************************************
-NAME:
- P_LAST_KILLER "last_killer"
+P_LAST_KILLER
+*************
-DEFINIERT IN:
- /sys/player.h
+********************* VERALTETE PROPERTY
+****************************** * Diese Property ist veraltet und wird
+bald aus der Mudlib entfernt. * ************************************
+***********************************
-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()
+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/props/obsolete/P_LAST_PEACE_TIME b/doc/props/obsolete/P_LAST_PEACE_TIME
index 762233e..f8aea49 100644
--- a/doc/props/obsolete/P_LAST_PEACE_TIME
+++ b/doc/props/obsolete/P_LAST_PEACE_TIME
@@ -1,27 +1,41 @@
-********************* VERALTETE PROPERTY ******************************
-* Diese Property ist veraltet und wird bald aus der Mudlib entfernt. *
-***********************************************************************
-PROPERTY
- P_LAST_PEACE_TIME "last_peace_time"
+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
+ /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.
+ 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
+ QueryPacify, P_ACCEPT_PEACE
+
LETZTE AENDERUNG
+================
- 2004-03-17, 14:30 von Humni
-
-
+ 2004-03-17, 14:30 von Humni
diff --git a/doc/props/obsolete/P_LOG_FILE b/doc/props/obsolete/P_LOG_FILE
index 1eafe40..ed57133 100644
--- a/doc/props/obsolete/P_LOG_FILE
+++ b/doc/props/obsolete/P_LOG_FILE
@@ -1,45 +1,69 @@
-********************* VERALTETE PROPERTY ******************************
-* Diese Property wird nicht mehr ausgewertet. *
-***********************************************************************
-NAME:
- P_LOG_FILE "log_file"
-DEFINIERT IN:
- /sys/thing/properties.h
+P_LOG_FILE
+**********
-BESCHREIBUNG:
- Enthaelt einen String auf einen Filenamen.
+********************* VERALTETE PROPERTY
+****************************** * Diese Property wird nicht mehr
+ausgewertet. * ******************************
+*****************************************
- 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().
+NAME
+====
- Das heisst, es wird AUF JEDEN FALL nach /log geschrieben!
+ P_LOG_FILE "log_file"
- 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.
+DEFINIERT IN
+============
- SetProp(P_LOG_FILE,"tilly/tilly_log"); // RICHTIG!
+ /sys/thing/properties.h
- 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.
+BESCHREIBUNG
+============
-SIEHE AUCH:
- P_LOG_INFO, write_file(), log_file(),
+ 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/props/obsolete/P_NEXT_SPELL_TIME b/doc/props/obsolete/P_NEXT_SPELL_TIME
index 4742456..300a766 100644
--- a/doc/props/obsolete/P_NEXT_SPELL_TIME
+++ b/doc/props/obsolete/P_NEXT_SPELL_TIME
@@ -1,30 +1,49 @@
-********************* VERALTETE PROPERTY ******************************
-* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
-***********************************************************************
-NAME:
- P_NEXT_SPELL_TIME "next_spell"
+P_NEXT_SPELL_TIME
+*****************
-DEFINIERT IN:
- /sys/new_skills.h
+********************* VERALTETE PROPERTY
+****************************** * Diese Property ist veraltet. Bitte
+nicht mehr in neuem Code nutzen. * **********************************
+*************************************
-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.
+NAME
+====
-SIEHE AUCH:
- SetSpellFatigue(L), CheckSpellFatigue(L)
- spruchermuedung
+ P_NEXT_SPELL_TIME "next_spell"
-ZULETZT GEAeNDERT:
+
+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/props/obsolete/P_READ_MSG b/doc/props/obsolete/P_READ_MSG
index 5c79fdc..2331508 100644
--- a/doc/props/obsolete/P_READ_MSG
+++ b/doc/props/obsolete/P_READ_MSG
@@ -1,32 +1,56 @@
-********************* VERALTETE PROPERTY ******************************
-* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
-***********************************************************************
-NAME:
- P_READ_MSG "read_msg"
-DEFINIERT IN:
- /sys/properties.h
+P_READ_MSG
+**********
-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.
+********************* VERALTETE PROPERTY
+****************************** * Diese Property ist veraltet. Bitte
+nicht mehr in neuem Code nutzen. * **********************************
+*************************************
- 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()
+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/props/obsolete/P_TECHNIQUE b/doc/props/obsolete/P_TECHNIQUE
index 1657027..a556ce6 100644
--- a/doc/props/obsolete/P_TECHNIQUE
+++ b/doc/props/obsolete/P_TECHNIQUE
@@ -1,44 +1,70 @@
-********************* 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
+P_TECHNIQUE
+***********
-BESCHREIBUNG:
- Die Technik(en), mit denen eine Waffe im Kampf eingesetzt werden
- kann. Folgende Techniken stehen zur Verfuegung:
+********************* 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.
+* *******************************************************************
+****
- 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.
+NAME
+====
-BEMERKUNGEN:
- Man kann einer Waffe eine oder mehrere Techniken zuweisen.
+ P_TECHNIQUE "technique"
-BEISPIELE:
- a) Eine Waffe, die nur mit einer Peitschtechnik eingesetzt wird,
- also typischerweise eine Peitsche, aber auch ein Morgenstern:
- SetProp(P_TECHNIQUE,TQ_WHIP);
+DEFINIERT IN
+============
- b) Eine Waffe, die sowohl mit der Schlag- als auch der Stosstechnik
- eingesetzt wird, also z.B. eine Hellebarde:
+ /sys/weapon.h
- SetProp(P_TECHNIQUE,({TQ_THRASH,TQ_THRUST}));
-SIEHE AUCH:
- techniken, P_BALANCED_WEAPON, /std/weapon/combat.c
+BESCHREIBUNG
+============
-LETZTE AeNDERUNG:
+ 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/props/obsolete/P_TMP_ATTACK_HOOK b/doc/props/obsolete/P_TMP_ATTACK_HOOK
index bdc8152..6bd5130 100644
--- a/doc/props/obsolete/P_TMP_ATTACK_HOOK
+++ b/doc/props/obsolete/P_TMP_ATTACK_HOOK
@@ -1,73 +1,95 @@
-********************* VERALTETE PROPERTY ******************************
-* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
-***********************************************************************
+
P_TMP_ATTACK_HOOK
+*****************
-NAME:
- P_TMP_ATTACK_HOOK "attack_hook"
+********************* VERALTETE PROPERTY
+****************************** * Diese Property ist veraltet. Bitte
+nicht mehr in neuem Code nutzen. * **********************************
+************************************* P_TMP_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.
+NAME
+====
- 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'.
+ P_TMP_ATTACK_HOOK "attack_hook"
- Der Methode wird als Parameter der Gegner uebergeben.
- Gibt die Methode 0 als Rueckgabewert zurueck, wird die Attacke sofort
- kommentarlos abgebrochen.
+DEFINIERT IN
+============
-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
+ /sys/new_skills.h
-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) {
+BESCHREIBUNG
+============
- // 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)) {
+ Mittels dieser Property koennen die Attacken eines Livings ggf.
+ abgebrochen werden noch bevor Waffen oder Skills zum ausgewertet
+ wurden.
- 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;
- }
+ 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'.
- // ansonsten geht der Angriff weiter
- return 1;
+ 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;
}
-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
+ // 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/props/obsolete/P_TMP_ATTACK_MOD b/doc/props/obsolete/P_TMP_ATTACK_MOD
index 3491c0c..df10409 100644
--- a/doc/props/obsolete/P_TMP_ATTACK_MOD
+++ b/doc/props/obsolete/P_TMP_ATTACK_MOD
@@ -1,112 +1,134 @@
-********************* VERALTETE PROPERTY ******************************
-* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
-***********************************************************************
+
P_TMP_ATTACK_MOD
+****************
-NAME:
- P_TMP_ATTACK_MOD "attack_mod"
+********************* VERALTETE PROPERTY
+****************************** * Diese Property ist veraltet. Bitte
+nicht mehr in neuem Code nutzen. * **********************************
+************************************* P_TMP_ATTACK_MOD
-DEFINIERT IN:
- /sys/new_skills.h
-BESCHREIBUNG:
- Mittels dieser Property koennen die Attacken eines Livings temporaer
- veraendert werden.
+NAME
+====
- 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'.
+ P_TMP_ATTACK_MOD "attack_mod"
- 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.
+DEFINIERT IN
+============
-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
+ /sys/new_skills.h
-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()) {
+BESCHREIBUNG
+============
- object wield;
- wield=TP->QueryProp(P_WEAPON);
+ Mittels dieser Property koennen die Attacken eines Livings temporaer
+ veraendert werden.
- write(break_string(
- "Der Priester der Flamme weiht "+
- (wield?wield->name(WEN,1):"deine Haende")+".", 78));
+ 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'.
- // setzen des Modifiers .. 30-40 Sekunden gueltig
- TP->SetProp(P_TMP_ATTACK_MOD,
- ({time()+30+random(10), this_object(), "modfun"}));
- } else ...
- ...
- return 1;
- }
+ 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,
+ ]);
- // die eigentlich Methode, die waehrend des Angriffs gerufen wird
- mapping modfun(mapping ainfo) {
- mapping ret;
+ 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.
- // 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);
- }
+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
+ 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/props/obsolete/P_TMP_DEFEND_HOOK b/doc/props/obsolete/P_TMP_DEFEND_HOOK
index 986e63a..f29d342 100644
--- a/doc/props/obsolete/P_TMP_DEFEND_HOOK
+++ b/doc/props/obsolete/P_TMP_DEFEND_HOOK
@@ -1,110 +1,131 @@
-********************* VERALTETE PROPERTY ******************************
-* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
-***********************************************************************
+
P_TMP_DEFEND_HOOK
+*****************
-NAME:
- P_TMP_DEFEND_HOOK "defend_hook"
+********************* VERALTETE PROPERTY
+****************************** * Diese Property ist veraltet. Bitte
+nicht mehr in neuem Code nutzen. * **********************************
+************************************* P_TMP_DEFEND_HOOK
-DEFINIERT IN:
- /sys/new_skills.h
-BESCHREIBUNG:
- Mittels dieser Property koennen die Abwehren eines Livings temporaer
- veraendert werden.
+NAME
+====
- 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'.
+ P_TMP_DEFEND_HOOK "defend_hook"
- 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.
+DEFINIERT IN
+============
- 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
+ /sys/new_skills.h
-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);
+BESCHREIBUNG
+============
- // 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");
- }
- ...
+ Mittels dieser Property koennen die Abwehren eines Livings temporaer
+ veraendert werden.
- // 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))) {
+ 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'.
- // 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()}));
+ 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
- // manchmal geht der Zauber dabei endgueltig kaputt
- if(!random(10)) previous_object()->SetProp(P_TMP_DEFEND_HOOK, 0);
+ Zudem findet der Aufruf der Methode nach dem Abarbeiten der P_DEFENDERS
+ statt, diese koennen also weitere Modifikationen vorgenommen haben.
- return 0; // volles Abfangen des Angriffs
- }
+ 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
- // 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}));
- }
+BEMERKUNGEN
+===========
- // der Zauber schuetzt dann gar nicht ...
- return 1;
+ - 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
}
-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
+ // 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/props/obsolete/P_TMP_DIE_HOOK b/doc/props/obsolete/P_TMP_DIE_HOOK
index cd18917..f4008cb 100644
--- a/doc/props/obsolete/P_TMP_DIE_HOOK
+++ b/doc/props/obsolete/P_TMP_DIE_HOOK
@@ -1,70 +1,91 @@
-********************* VERALTETE PROPERTY ******************************
-* Diese Property ist veraltet. Bitte nicht mehr in neuem Code nutzen. *
-***********************************************************************
+
P_TMP_DIE_HOOK
+**************
-NAME:
- P_TMP_DIE_HOOK "die_hook"
+********************* VERALTETE PROPERTY
+****************************** * Diese Property ist veraltet. Bitte
+nicht mehr in neuem Code nutzen. * **********************************
+************************************* P_TMP_DIE_HOOK
-DEFINIERT IN:
- /sys/new_skills.h
-BESCHREIBUNG:
- Mittels dieser Property kann der Tod eines Livings abgewendet werden.
+NAME
+====
- 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.
+ P_TMP_DIE_HOOK "die_hook"
- 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.
+DEFINIERT IN
+============
-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
+ /sys/new_skills.h
-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;
+BESCHREIBUNG
+============
- 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()}));
+ Mittels dieser Property kann der Tod eines Livings abgewendet werden.
- ret=1;
- }
+ 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.
- // wir helfen nur einmal ... und ein Tod vernichtet die Hilfe auch
- previous_object()->SetProp(P_TMP_DIE_HOOK, 0);
+ Der Methode wird ein int uebergeben, ob das Living Opfer von Gift
+ (P_POISON) war.
- return ret;
+ 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;
}
-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
+ // 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/props/obsolete/P_TMP_MOVE_HOOK b/doc/props/obsolete/P_TMP_MOVE_HOOK
index c28a067..8f1aa77 100644
--- a/doc/props/obsolete/P_TMP_MOVE_HOOK
+++ b/doc/props/obsolete/P_TMP_MOVE_HOOK
@@ -1,42 +1,65 @@
-********************* 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
+P_TMP_MOVE_HOOK
+***************
-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!
+********************* VERALTETE PROPERTY
+****************************** * Diese Property ist veraltet. Bitte
+nicht mehr in neuem Code nutzen. * **********************************
+*************************************
-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
+NAME
+====
-SIEHE AUCH:
- Bewegung: move(L), NotifyMove(), PreventMove()
- Hooks: P_TMP_DIE_HOOK, P_TMP_DEFEND_HOOK, P_TMP_ATTACK_HOOK
- neue Hooks: std/hooks
+ 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/props/skill_info_liste b/doc/props/skill_info_liste
index 011f616..a8ad089 100644
--- a/doc/props/skill_info_liste
+++ b/doc/props/skill_info_liste
@@ -1,315 +1,355 @@
+
+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).
+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.
+ #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_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_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_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_SKILLDAMAGE_MSG: string
+ Meldung anstatt der Waffe oder Haende-Meldung.
- 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_SKILLDAMAGE_MSG2: string
+ Meldung anstatt der Waffe oder Haende-Meldung fuer den Raum.
- 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_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_LASTLIGHT: int
- Zeitpunkt, bis wann der Standardskills SK_NIGHTVISION den Spieler
- sehen laesst.
+ 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.
- 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!
+ FACTOR(SI_DIFFICULTY): int / mixed OFFSET(SI_DIFFICULTY): int /
+ mixed
- 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!
+ Nur fuer Spellbooks/Spells. Der mixed-Parameter kann
+ Funktionen enthalten. Siehe unten bei SI_SPELLCOST.
- 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_LASTLIGHT: int
+ Zeitpunkt, bis wann der Standardskills SK_NIGHTVISION den
+ Spieler sehen laesst.
- 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_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_MAGIC_TYPE: string*
- Enthaelt ein Array der Magietypen, die zum Einsatz kommen. Die Angabe
- geschieht zB im Spellbook und beeinflusst SpellDefend().
+ 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_LAST_USE: int (eventuell obsolet)
- Letzte Nutzung des Skills.
-
- SI_LEARN_PROB: int (eventuell obsolet)
- Lernwahrscheinlichkeit.
+ 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,
- SI_SKILLDURATION: int
- Dauer des Skills/Spells. Momentan nicht allzu verbreitet in Nutzung.
+ SK_TWOHANDED, SK_SPELL_DEFEND, SK_INFORM_DEFEND und
+ SK_DEFEND_OTHER.
- #2 nur fuer Spells:
- SI_SPELLBOOK: string
- Kann direkt das enthaltende Spellbook fuer einen Spell enthalten.
+ 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.
- 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_MAGIC_TYPE: string*
+ Enthaelt ein Array der Magietypen, die zum Einsatz kommen.
+ Die Angabe geschieht zB im Spellbook und beeinflusst
+ SpellDefend().
- 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_LAST_USE: int (eventuell obsolet)
+ Letzte Nutzung des Skills.
- 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_LEARN_PROB: int (eventuell obsolet)
+ Lernwahrscheinlichkeit.
- 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_SKILLDURATION: int
+ Dauer des Skills/Spells. Momentan nicht allzu verbreitet in
+ Nutzung.
- SI_PREPARE_MSG: string
- Meldung, die dem Spieler ausgegeben werden soll, wenn er einen Spell
- vorbereitet. Ansonsten wird ein Standardtext ausgegeben.
+ #2 nur fuer Spells:
+ SI_SPELLBOOK: string
+ Kann direkt das enthaltende Spellbook fuer einen Spell
+ enthalten.
- SI_PREPARE_BUSY_MSG: string
- Meldung, die dem Spieler ausgegeben werden soll, wenn er schon diesen
- Spell vorbereitet. Ansonsten wird ein Standardtext ausgegeben.
+ 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_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_SPELLCOST: int / mixed FACTOR(SI_SPELLCOST): int / mixed
+ OFFSET(SI_SPELLCOST): int / mixed
- 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.
+ 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_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_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_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_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_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_PREPARE_MSG: string
+ Meldung, die dem Spieler ausgegeben werden soll, wenn er
+ einen Spell vorbereitet. Ansonsten wird ein Standardtext
+ ausgegeben.
- 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_PREPARE_BUSY_MSG: string
+ Meldung, die dem Spieler ausgegeben werden soll, wenn er
+ schon diesen Spell vorbereitet. Ansonsten wird ein
+ Standardtext ausgegeben.
- 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_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_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_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_SKILLINFO: string
- SI_SKILLINFO_LONG: string
- Beschreibung des Spells. Wird im Gildenobjekt eingetragen und
- SI_SKILLINFO wird von SkillListe angezeigt.
+ SI_NOMAGIC_MSG: string
+ Meldung, die bei Fehlschlag durch P_NOMAGIC des Raumes
+ ausgegeben wird. Ansonsten wird ein Standardtext ausgegeben.
- 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_SPELLFATIGUE: int / mixed FACTOR(SI_SPELLFATIGUE): int /
+ mixed OFFSET(SI_SPELLFATIGUE): int / mixed
- 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.
+ 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.
- 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_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_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_SKILLLEARN: int / mixed FACTOR(SI_SKILLLEARN): int / mixed
+ OFFSET(SI_SKILLLEARN): int / mixed
- 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()
+ 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_SKILLHEAL: int
- Konvention fuer Spells im Spellbook, dort den Heilwert zu hinterlegen,
- hat keine Auswirkungen unter /std/.
+ 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_USR: mixed
- Fuer selbst definierte Infos, spellbookabhaengig.
+ 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_PREPARE_TIME: int
- Dauer der Zeit fuer zu praeparierende Spells.
+ 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_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_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_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_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_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.
+ SI_SKILLINFO: string SI_SKILLINFO_LONG: string
-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
+ 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/sefun.index b/doc/sefun.index
new file mode 100644
index 0000000..6d9564f
--- /dev/null
+++ b/doc/sefun.index
@@ -0,0 +1,137 @@
+
+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/sefun/CountUp b/doc/sefun/CountUp
index 5515780..9e55d69 100644
--- a/doc/sefun/CountUp
+++ b/doc/sefun/CountUp
@@ -1,25 +1,40 @@
-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 "
+CountUp()
+*********
-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.
+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/sefun/_notify_fail b/doc/sefun/_notify_fail
index 84aa4de..a9801ef 100644
--- a/doc/sefun/_notify_fail
+++ b/doc/sefun/_notify_fail
@@ -1,18 +1,35 @@
+
+_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.
+FUNKTION
+========
-SIEHE AUCH:
- notify_fail(E), P_ACTUAL_NOTIFY_FAIL
- add_action(E), AddCmd(L), AddAction(L),
- query_verb(E)
+ 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/sefun/break_string b/doc/sefun/break_string
index 52d4d7b..8e3017d 100644
--- a/doc/sefun/break_string
+++ b/doc/sefun/break_string
@@ -1,90 +1,112 @@
-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'
+break_string()
+**************
-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.
+FUNKTION
+========
- Analog wird bei der Angabe der Zahl 'space' ein String mit 'space' Leer-
- zeichen vor jede umgebrochene Zeile gesetzt.
+ 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)
- 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.
+ARGUMENTE
+=========
-RUECKGABEWERT:
- Der umgebrochene Text.
+ 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'
- 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));
+BESCHREIBUNG
+============
- => Dies ist ein laengerer
- Text. Nur so als Beispiel.
+ 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.
- write(break_string("Mit indent sieht das so aus", 30, "Wargon sagt: "));
+ Gibt man zusaetzlich noch einen String 'indent' an, so wird dieser vor
+ jede der umgebrochenen Zeilen gesetzt.
- => Wargon sagt: Mit indent sieht
- Wargon sagt: das so aus
+ Analog wird bei der Angabe der Zahl 'space' ein String mit 'space' Leer-
+ zeichen vor jede umgebrochene Zeile gesetzt.
- write(break_string("Mit indent sieht das so aus", 30, "Wargon sagt: ",
- BS_INDENT_ONCE));
+ Zusaetzlich gibt es folgende optionale Flags, die man beliebig kombinieren
+ kann:
- => Wargon sagt: Mit indent sieht
- das so aus
+ 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.
- write(break_string("Mit Leerzeichen sieht das so aus", 30, 2));
- => Mit Leerzeichen sieht das so
- aus...
+RUECKGABEWERT
+=============
- write(break_string("Ich will es\naber vorformatiert!",60,
- "Wargon sagt: ", BS_LEAVE_MY_LFS));
+ Der umgebrochene Text.
- => Wargon sagt: Ich will es
- Wargon sagt: aber vorformatiert!
+ Laufzeit-Fehler, wenn der Indent laenger ist als die vorgegebene Breite.
- write(break_string("Ich will es\naber vorformatiert!",30,
- "Wargon sagt: ", BS_PREPEND_INDENT));
- => Wargon sagt:
- Ich will es aber
- vorformatiert!
+BEISPIELE
+=========
-SIEHE AUCH:
- senderwiederholung
+ 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/sefun/broken_count_bits b/doc/sefun/broken_count_bits
index 09e56b8..de01e96 100644
--- a/doc/sefun/broken_count_bits
+++ b/doc/sefun/broken_count_bits
@@ -1,29 +1,48 @@
+
+broken_count_bits()
+*******************
+
+
SYNOPSIS
- int count_bits (string str)
+========
+
+ int count_bits (string str)
+
DESTRIPTION
- Count the number of set bits in bitstring <str> and return the number
- as result.
+===========
+
+ 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.
+====
+
+ 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);
+ string s;
- count_bits(s) --> returns 2
+ 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)
+========
+
+ 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/sefun/cindent b/doc/sefun/cindent
index 72119b3..e0e16af 100644
--- a/doc/sefun/cindent
+++ b/doc/sefun/cindent
@@ -1,9 +1,22 @@
-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).
+cindent()
+*********
-SEE ALSO:
- ed(E)
+
+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/sefun/debug_info b/doc/sefun/debug_info
index 18747b0..02e02b8 100644
--- a/doc/sefun/debug_info
+++ b/doc/sefun/debug_info
@@ -1,490 +1,508 @@
-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)
+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.
+ Sammelt entsprechend den Angaben in <flag> gewisse intere Debuginfos
+ des Treibers. <flag> kann dabei folgende in debug_info.h definierte
+ Werte enthalten:
- 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_OBJECT (0): Angezeigt werden Informationen zum in <arg>
+ spezifizierten Objekt, zum Beispiel heart_beat,
+ enable_commands 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_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_MALLOC (3): Entsprichend der Eingabe des 'malloc'-Kommandos.
- Es muessen keine weiteren Argumente angegeben werden.
+ 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_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_MALLOC (3): Entsprichend der Eingabe des 'malloc'-Kommandos.
+ Es muessen keine weiteren Argumente angegeben werden.
- 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.
+ 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.
- <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.
+ 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> == "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> == "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> == "opcodes": liefert Nutzungsinformationen ueber die
- opcodes. Standardmaessig wird in die Datei /OPC_DUMP
- geschrieben. valid_write() wird 'opcdump' uebergeben.
+ <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> == "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.
+ <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.
+ 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_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_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.
+ <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.
+ 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:
+ 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_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_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_MAX_FREE:
+ Maximale Anzahl freier Bloecke dieser
+ Groesse.
- int DID_MEM_ES_CUR_FREE:
- Derzeitige 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_XALLOC:
+ Durchschnittliche Zahl von Allokationen pro
+ Sekunde.
- float DID_MEM_ES_AVG_XFREE:
- Durchschnittliche Zahl von Deallokationen pro
- Sekunde.
+ float DID_MEM_ES_AVG_XFREE:
+ Durchschnittliche Zahl von Deallokationen pro
+ Sekunde.
- Die Durchschnittsstatistiken schliessen interne
- Umsortierungen der Blocklisten nicht ein.
+ 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.
+ 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)
+ <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 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.
+ 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.
+ 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.
+ 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_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).
+ <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
+ 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.
+ 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.
+ 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.
+==========
+
+ 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)
+==========
+
+ trace(E), traceprefix(E), malloc(D), status(D), dumpallobj(D)
diff --git a/doc/sefun/deep_present b/doc/sefun/deep_present
index 78c0983..c3f673a 100644
--- a/doc/sefun/deep_present
+++ b/doc/sefun/deep_present
@@ -1,21 +1,40 @@
-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
+deep_present()
+**************
-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
+FUNKTION
+========
-SIEHE AUCH:
- present(E)
+ 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/sefun/dtime b/doc/sefun/dtime
index 6624642..dac7dd0 100644
--- a/doc/sefun/dtime
+++ b/doc/sefun/dtime
@@ -1,24 +1,49 @@
-FUNKTION:
- string dtime(int time)
-ARGUMENTE:
- time - Umzuwandelndes Datum in Sekunden seit 1.1.1970, 0:0:0h
+dtime()
+*******
-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.
+FUNKTION
+========
-BEMERKUNGEN:
- Als time wird meistens das Ergebnis von time() benutzt.
- strftime() stellt eine wesentlich flexiblere Moeglichkeit der Ausgabe von
- Zeiten dar.
+ string dtime(int time)
-BEISPIELE:
- datum = dtime(time());
- => datum = "Mon, 6. Mar 1994, 15:00:08"
-SIEHE AUCH:
- ctime(E), strftime(E), time(E)
+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/sefun/dump_netdead b/doc/sefun/dump_netdead
index c73b2c0..b5b480a 100644
--- a/doc/sefun/dump_netdead
+++ b/doc/sefun/dump_netdead
@@ -1,13 +1,29 @@
-FUNKTION:
- string *dump_netdead()
-BESCHREIBUNG:
- Gibt ein Array mit den Namen aller zur Zeit netztoten Spieler
- zurueck.
+dump_netdead()
+**************
-RUECKGABEWERT:
- Ein Stringarray mit den Namen der netztoten Spieler.
- gibt.
-SIEHE AUCH:
- find_netdead(E)
+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/sefun/enable_commands b/doc/sefun/enable_commands
index 6508b5f..593fb31 100644
--- a/doc/sefun/enable_commands
+++ b/doc/sefun/enable_commands
@@ -1,26 +1,42 @@
+
+enable_commands()
+*****************
+
+
SYNOPSIS
- void enable_commands();
+========
+
+ 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.
+ 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".
+ 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)
+==========
+
+ command(E), living(E), disable_commands(E), native(C), hooks(C)
+ set_living_name(E)
diff --git a/doc/sefun/file_time b/doc/sefun/file_time
index 6c24baa..ddaefce 100644
--- a/doc/sefun/file_time
+++ b/doc/sefun/file_time
@@ -1,5 +1,13 @@
-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.
+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/sefun/find_living b/doc/sefun/find_living
index 106dd63..5930695 100644
--- a/doc/sefun/find_living
+++ b/doc/sefun/find_living
@@ -1,22 +1,42 @@
-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.
+find_living()
+*************
-BEISPIEL:
- object ob;
- ob = find_living("Public Enemy");
-SIEHE AUCH:
- find_player(E), enable_commands(E), set_living_name(E)
+SYNOPSIS
+========
-LETZTE AeNDERUNG:
+ 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/sefun/find_livings b/doc/sefun/find_livings
index cc9228f..7f8f9b1 100644
--- a/doc/sefun/find_livings
+++ b/doc/sefun/find_livings
@@ -1,24 +1,49 @@
-FUNKTION:
- object *find_livings(string name)
-ARGUMENTE:
- name - der living_name der gesuchten Lebewesen
+find_livings()
+**************
-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.
+FUNKTION
+========
-BEISPIELE:
- ob = find_livings("herkules");
- => ob = ({ [/human:herkules],
- [/d/inseln/wargon/luftschloss/mon/herkules] })
+ object *find_livings(string name)
-SIEHE AUCH:
- find_living(E), set_living_name(E), find_player(E), find_netdead(E)
-LETZTE AENDERUNG:
+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/sefun/find_netdead b/doc/sefun/find_netdead
index d44ee9e..8686436 100644
--- a/doc/sefun/find_netdead
+++ b/doc/sefun/find_netdead
@@ -1,25 +1,46 @@
-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).
+find_netdead()
+**************
-RUECKGABEWERT:
- Der netztote Spieler oder 0, falls es keinen Netztoten diesen Namens
- gibt.
+FUNKTION
+========
-SIEHE AUCH:
- find_living(E), find_player(E)
+ object find_netdead(string name)
-LETZT AeNDERUNG:
+
+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/sefun/find_player b/doc/sefun/find_player
index 57c85f3..048b105 100644
--- a/doc/sefun/find_player
+++ b/doc/sefun/find_player
@@ -1,42 +1,60 @@
-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).
+find_player()
+*************
- Rueckgabewert ist das Spielerobjekt (wenn Spieler anwesend),
- ansonsten 0.
-BEISPIEL:
+FUNKTION
+========
- object ob;
- ob = find_player("deepthought");
+ object find_player(string uid)
- if(ob)
- tell_object(ob,"Tach Du!\n");
- oder auch
+BESCHREIBUNG
+============
- if(ob = find_player("deepthought"))
- tell_object(ob,"Tach Du!\n");
+ Findet den Spieler mit dem Namen bzw. der User-ID <uid>.
-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)
+ 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).
-----------------------------------------------------------------------------
-Letzte Aenderung: 06.01.2009, Zesstra
+ 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/sefun/getuuid b/doc/sefun/getuuid
index 5b34343..63ea31e 100644
--- a/doc/sefun/getuuid
+++ b/doc/sefun/getuuid
@@ -1,17 +1,29 @@
-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.
+getuuid()
+*********
- 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.
-
+SYNOPSIS
+========
-SEE ALSO:
- getuid(E)
+ 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/sefun/iso2ascii b/doc/sefun/iso2ascii
index fe7757a..bd64d73 100644
--- a/doc/sefun/iso2ascii
+++ b/doc/sefun/iso2ascii
@@ -1,17 +1,32 @@
-FUNKTION:
- public string iso2ascii( string str );
-ARGUMENTE:
- str
- String, in welchem Zeichen ersetzt werden sollen.
+iso2ascii()
+***********
-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.
+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/sefun/log_file b/doc/sefun/log_file
index 6cdab31..a3f3cab 100644
--- a/doc/sefun/log_file
+++ b/doc/sefun/log_file
@@ -1,35 +1,59 @@
-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)
+log_file()
+**********
-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.
+FUNKTION
+========
-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.
+ int log_file(string file, string text)
+ int log_file(string file, string text, int size_to_break)
-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)
+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/sefun/lowerchar b/doc/sefun/lowerchar
index 0ec62bf..8e6cfdd 100644
--- a/doc/sefun/lowerchar
+++ b/doc/sefun/lowerchar
@@ -1,20 +1,42 @@
-FUNKTION:
- int lowerchar(int char)
-ARGUMENTE:
- char - Das umzuwandelnde Zeichen
+lowerchar()
+***********
-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.
+FUNKTION
+========
-BEISPIELE:
- printf("%c\n", lowerchar('A')); => a
- printf("%c\n", lowerchar('1')); => 1
+ int lowerchar(int char)
-SIEHE AUCH:
- lower_case(E), lowerstring(E), upperstring(E), capitalize(E)
+
+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/sefun/lowerstring b/doc/sefun/lowerstring
index 30748fc..a483224 100644
--- a/doc/sefun/lowerstring
+++ b/doc/sefun/lowerstring
@@ -1,20 +1,45 @@
-FUNKTION:
- string lowerstring(string str)
-ARGUMENTE:
- str - Der umzuwandelnde String.
+lowerstring()
+*************
-BESCHREIBUNG:
- Alle Grossbuchstaben in str werden in Kleinbuchstaben umgewandelt.
-RUECKGABEWERT:
- Der umgewandelte String.
+FUNKTION
+========
-BEMERKUNGEN:
- lowerstring ist mit lower_case identisch!
+ string lowerstring(string str)
-BEISPIELE:
- s = lowerstring("So, McLaud...\n"); => s = "so, mclaud...\n"
-SIEHE AUCH:
- lower_case(E), lowerchar(E), upperstring(E), capitalize(E)
+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/sefun/m_copy_delete b/doc/sefun/m_copy_delete
index cb1c97b..9aa90f2 100644
--- a/doc/sefun/m_copy_delete
+++ b/doc/sefun/m_copy_delete
@@ -1,43 +1,68 @@
-FUNKTION:
- mapping m_copy_delete(mapping map, mixed key)
-ARGUMENTE:
- map - das Mapping, aus dem geloescht werden soll.
- key - der zu loeschende Eintrag
+m_copy_delete()
+***************
-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.
+FUNKTION
+========
-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.
+ mapping m_copy_delete(mapping map, mixed key)
-BEISPIELE:
- mapping m1, m2;
- m1 = ([ "a":1, "b":2, "c":3 ]);
+ARGUMENTE
+=========
- m2 = m_copy_delete(m1, "b");
- => m1 = ([ "a":1, "b":2, "c":3 ])
- m2 = ([ "a":1, "c":3 ])
+ map - das Mapping, aus dem geloescht werden soll.
+ key - der zu loeschende Eintrag
- m_copy_delete(m1, "a");
- => (es hat sich nichts geaendert)
- m1 = m_copy_delete(m1, "a");
- => m1 = ([ "b":2, "c":3 ])
+BESCHREIBUNG
+============
- Im letzten Fall sollte aber besser efun::m_delete(m1, "a") benutzt
- werden, da ansonsten das Mapping unnoetig kopiert wird und Rechen-
- leistung frisst.
+ Aus dem Mapping map wird der Eintrag key geloescht (wenn er in map vor-
+ handen ist). map wird dabei nicht veraendert.
-SIEHE AUCH:
- efun::m_delete(E), mappingp(E), mkmapping(E), m_indices,(E) m_values(E),
- sizeof(E), widthof(E)
+
+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/sefun/match_living b/doc/sefun/match_living
index 44801a8..5cb347b 100644
--- a/doc/sefun/match_living
+++ b/doc/sefun/match_living
@@ -1,30 +1,52 @@
+
+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.
+FUNKTION
+========
-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.
+ varargs mixed match_living( string str, int players_only,
+ string *exclude)
-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)
+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/sefun/md5 b/doc/sefun/md5
index 1e65090..f48dcc8 100644
--- a/doc/sefun/md5
+++ b/doc/sefun/md5
@@ -1,30 +1,52 @@
+
+md5()
+*****
+
+
DEPRECATED
+==========
+
+
SYNOPSIS
- string md5 (string arg [ , int iterations ] )
- string md5 (int * arg [ , int iterations ] )
+========
+
+ 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.
+ 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).
- 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.
+ 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 )
+ 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.
+===========
+
+ 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)
+==========
+
+ crypt(E), md5_crypt(E), sha1(E), hash(E), hmac(E)
diff --git a/doc/sefun/mkdirp b/doc/sefun/mkdirp
index a05d4e6..2bb9d06 100644
--- a/doc/sefun/mkdirp
+++ b/doc/sefun/mkdirp
@@ -1,21 +1,42 @@
-FUNKTION:
- int mkdirp(string dir)
-ARGUMENTE:
- dir - Name des zu erstellenden Verzeichnisses (absolut)
+mkdirp()
+********
-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)
+FUNKTION
+========
-LETZT AeNDERUNG:
+ 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/sefun/notify_fail b/doc/sefun/notify_fail
index 1970367..85b700a 100644
--- a/doc/sefun/notify_fail
+++ b/doc/sefun/notify_fail
@@ -1,85 +1,107 @@
-FUNKTION:
- #include <notify_fail.h>
- varargs void notify_fail(string str, int prio)
- varargs void notify_fail(closure cl, int prio)
+notify_fail()
+*************
-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.
+FUNKTION
+========
- Gedacht ist notify_fail, um dem Spieler eine bessere Hilfestellung
- bei Kommandos / Eingaben zu geben, um ihn u.U. auf die richtige
- Syntax hinzuweisen.
+ #include <notify_fail.h>
- 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
+ varargs void notify_fail(string str, int prio)
+ varargs void notify_fail(closure cl, int prio)
- 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.
+ARGUMENTE
+=========
-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.
+ 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
-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");
+BESCHREIBUNG
+============
- // 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.
+ Merkt sich den angegebenen str und gibt ihn im Falle einer inkorrekten
+ Eingabe des Spielers anstatt eines 'Wie bitte' aus.
- if(!str || str!="suppe") return 0;
- // ab hier ist die Eingabe dann wirklich 'suppe' und die Funktion
- // kann beliebig fortgefuehrt werden
- ...
- return 1;
+ Gedacht ist notify_fail, um dem Spieler eine bessere Hilfestellung
+ bei Kommandos / Eingaben zu geben, um ihn u.U. auf die richtige
+ Syntax hinzuweisen.
-SIEHE AUCH:
- add_action(E), AddCmd(L), AddAction(L),
- query_verb(E), query_notify_fail(E)
+ 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/sefun/object_info b/doc/sefun/object_info
index 3945651..bee892e 100644
--- a/doc/sefun/object_info
+++ b/doc/sefun/object_info
@@ -1,129 +1,148 @@
-DEPRECATED
-SYNOPSIS
- #include <objectinfo.h>
- mixed * object_info(object ob, int what)
- mixed * object_info(object ob, int what, int index)
+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.
+ Returns some internal information about object <ob>, collected
+ in an array. Argument <what> determines which information is
+ returned.
- 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!
+ 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:
+ <what> == OINFO_BASIC:
- This call returns basic information about <ob>:
+ 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.
+ 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:
+ <what> == OINFO_POSITION:
- This call returns information about <ob>'s position in the
- global list of objects:
+ 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.
+ 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.
+ This call can be expensive in computing time.
- <what> == OINFO_MEMORY:
+ <what> == OINFO_MEMORY:
- This call returns information about the program <ob> uses:
+ 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.
+ 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.
+ 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.
+=======
+
+ 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)
+========
+
+ debug_info(E)
diff --git a/doc/sefun/obsolete/exclude_alist b/doc/sefun/obsolete/exclude_alist
index a967a14..5d1aace 100644
--- a/doc/sefun/obsolete/exclude_alist
+++ b/doc/sefun/obsolete/exclude_alist
@@ -1,4 +1,11 @@
-SYNOPSIS:
- mixed *exclude_alist(int i, mixed *alist)
+
+exclude_alist()
+***************
+
+
+SYNOPSIS
+========
+
+ mixed *exclude_alist(int i, mixed *alist)
Remove element i from alist.
diff --git a/doc/sefun/obsolete/remove_alist b/doc/sefun/obsolete/remove_alist
index cf9bc61..fceac4f 100644
--- a/doc/sefun/obsolete/remove_alist
+++ b/doc/sefun/obsolete/remove_alist
@@ -1,3 +1,7 @@
-mixed *remove_alist(mixed key, mixed *alist)
+
+remove_alist()
+**************
+
+mixed >>*<<remove_alist(mixed key, mixed >>*<<alist)
Removes element associated by key key from alist.
diff --git a/doc/sefun/old_explode b/doc/sefun/old_explode
index 6b13d8e..357e838 100644
--- a/doc/sefun/old_explode
+++ b/doc/sefun/old_explode
@@ -1,28 +1,53 @@
-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.
+old_explode()
+*************
-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.
+FUNKTION
+========
-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!
+ string *old_explode(string str, string del)
-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)
+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/sefun/process_call b/doc/sefun/process_call
index c00a039..cd43faf 100644
--- a/doc/sefun/process_call
+++ b/doc/sefun/process_call
@@ -1,21 +1,38 @@
+
+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!");
- }
+FUNKTION
+========
-SIEHE AUCH:
- notify_fail(E), process_string(E), replace_personal(E)
+ 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/sefun/process_string b/doc/sefun/process_string
index 75c9290..fbc7018 100644
--- a/doc/sefun/process_string
+++ b/doc/sefun/process_string
@@ -1,57 +1,77 @@
+
+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");
- }
+FUNKTION
+========
- -> bei Abfrage: "Ein huebsch gelbes Ding."
+ string process_string(string str)
+ string process_string(closure cl)
-SIEHE AUCH:
- notify_fail(E), process_call(E), replace_personal(E)
+
+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/sefun/query_editing b/doc/sefun/query_editing
index 010c98e..32358ed 100644
--- a/doc/sefun/query_editing
+++ b/doc/sefun/query_editing
@@ -1,13 +1,29 @@
+
+query_editing()
+***************
+
+
DEPRECATED
+==========
+
+
SYNOPSIS
- mixed query_editing(object ob);
+========
+
+ 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.
+============
+
+ 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)
+==========
+
+ ed(E)
diff --git a/doc/sefun/query_idle b/doc/sefun/query_idle
index 7c0a0a5..7deccee 100644
--- a/doc/sefun/query_idle
+++ b/doc/sefun/query_idle
@@ -1,8 +1,21 @@
+
+query_idle()
+************
+
+
SYNOPSIS
- int query_idle(object ob);
+========
+
+ int query_idle(object ob);
+
BESCHREIBUNG
- Gibt an, seit wie vielen Sekunden ein Player Objekt <ob> idle ist.
+============
+
+ Gibt an, seit wie vielen Sekunden ein Player Objekt <ob> idle ist.
+
SIEHE AUCH
- interactive(E)
+==========
+
+ interactive(E)
diff --git a/doc/sefun/query_input_pending b/doc/sefun/query_input_pending
index 8033cec..c40c355 100644
--- a/doc/sefun/query_input_pending
+++ b/doc/sefun/query_input_pending
@@ -1,11 +1,27 @@
+
+query_input_pending()
+*********************
+
+
DEPRECATED
+==========
+
+
SYNOPSIS
- object query_input_pending(object ob);
+========
+
+ 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.
+============
+
+ 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)
+==========
+
+ input_to(E), find_input_to(E), input_to_info(E), remove_input_to(E)
diff --git a/doc/sefun/query_ip_name b/doc/sefun/query_ip_name
index d16298f..76de80f 100644
--- a/doc/sefun/query_ip_name
+++ b/doc/sefun/query_ip_name
@@ -1,12 +1,28 @@
+
+query_ip_name()
+***************
+
+
GESCHUETZT
+==========
+
+
SYNOPSIS
- string query_ip_name(object ob);
+========
+
+ 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.
+============
+
+ 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)
+==========
+
+ query_ip_number(E)
diff --git a/doc/sefun/query_ip_number b/doc/sefun/query_ip_number
index a462aba..d09bc88 100644
--- a/doc/sefun/query_ip_number
+++ b/doc/sefun/query_ip_number
@@ -1,24 +1,43 @@
+
+query_ip_number()
+*****************
+
+
GESCHUETZT
+==========
+
+
SYNOPSIS
- string query_ip_number(object ob);
- string query_ip_number(mixed & ob);
+========
+
+ 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:
+ Liefert die IP-Nummer des Benutzers <ob> oder des aktuellen Benutzers,
+ wenn <ob> nicht angegeben wurde.
- ob[0 .. 1] : sin_family
- ob[2 .. 3] : sin_port
- ob[4 .. 7] : sin_addr
- ob[8 ..15] : nicht definiert.
+ 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.
+===========
+
+ Die Rueckgabe von struct sockaddr_in wurde in 3.2.1@81 eingefuehrt.
+
SIEHE AUCH
- query_ip_name(E)
+==========
+
+ query_ip_name(E)
diff --git a/doc/sefun/query_limits b/doc/sefun/query_limits
index 954577a..8af988f 100644
--- a/doc/sefun/query_limits
+++ b/doc/sefun/query_limits
@@ -1,56 +1,82 @@
-DEPRECATED
-SYNOPSIS
- #include <sys/rtlimits.h>
- int *query_limits();
- int *query_limits(int default);
+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
+ Liefert ein Array mit den momentan gueltigen Laufzeit Limiten bzw.
+ die standardmaessigen Laufzeit Limiten, wenn <default> wahr ist.
+ Die Eintraege im gelieferten Array bedeuten:
- Ausser fuer LIMIT_COST ein Limit von '0' (auch LIMIT_UNLIMITED)
- bedeutet 'keine Limit'.
+ 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
- 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.
+ Ausser fuer LIMIT_COST ein Limit von '0' (auch LIMIT_UNLIMITED)
+ bedeutet 'keine Limit'.
-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.
+ 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.
+=========
+
+ 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.
+===========
+
+ Eingefuehrt in LDMud 3.2.7.
+ LIMIT_CALLOUTS wurde in LDMud 3.2.9 eingefuehrt.
+
SIEHE AUCH
- limited(E), set_limits(E)
+==========
+
+ limited(E), set_limits(E)
16.05.2007, Zesstra
-
diff --git a/doc/sefun/query_mud_port b/doc/sefun/query_mud_port
index 2e5c6d2..de4c1e2 100644
--- a/doc/sefun/query_mud_port
+++ b/doc/sefun/query_mud_port
@@ -1,23 +1,39 @@
+
+query_mud_port()
+****************
+
+
DEPRECATED
+==========
+
+
SYNOPSIS
- int query_mud_port(void)
- int query_mud_port(object user)
- int query_mud_port(int num)
+========
+
+ 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.
+ Returns the port number the parser uses for user connections.
- 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.
+ 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)
+========
+
+ query_udp_port(E)
diff --git a/doc/sefun/query_next_reset b/doc/sefun/query_next_reset
index 03bbd7e..528ae56 100644
--- a/doc/sefun/query_next_reset
+++ b/doc/sefun/query_next_reset
@@ -1,27 +1,47 @@
+
+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().
+FUNKTION
+========
- 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.
+ varargs int query_next_reset(object ob)
-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)
+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/sefun/query_once_interactive b/doc/sefun/query_once_interactive
index c794223..bfb8b55 100644
--- a/doc/sefun/query_once_interactive
+++ b/doc/sefun/query_once_interactive
@@ -1,8 +1,21 @@
+
+query_once_interactive()
+************************
+
+
SYNOPSIS
- int query_once_interactive(object obj);
+========
+
+ int query_once_interactive(object obj);
+
BESCHREIBUNG
- Wahr, wenn <obj> interaktiv ist oder dies einmal war.
+============
+
+ Wahr, wenn <obj> interaktiv ist oder dies einmal war.
+
SIEHE AUCH
- remove_interactive(E)
+==========
+
+ remove_interactive(E)
diff --git a/doc/sefun/query_shadowing b/doc/sefun/query_shadowing
index 3ce5d6a..aadf109 100644
--- a/doc/sefun/query_shadowing
+++ b/doc/sefun/query_shadowing
@@ -1,18 +1,38 @@
+
+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
+FUNKTION
+========
-SIEHE AUCH:
- Generell: shadow(E), unshadow(E)
- Rechte: query_allow_shadow(M), query_prevent_shadow(L)
+ object query_shadowing(object obj)
-23.02.2016, Zesstra
\ No newline at end of file
+
+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/sefun/query_snoop b/doc/sefun/query_snoop
index 4da8838..94e598a 100644
--- a/doc/sefun/query_snoop
+++ b/doc/sefun/query_snoop
@@ -1,10 +1,26 @@
+
+query_snoop()
+*************
+
+
DEPRECATED
+==========
+
+
SYNOPSIS
- object query_snoop(object victim)
+========
+
+ object query_snoop(object victim)
+
DESCRIPTION
- Returns the user who currently snoops victim. The calling
- object must be privileged by the master object.
+===========
+
+ Returns the user who currently snoops victim. The calling
+ object must be privileged by the master object.
+
SEE ALSO
- snoop(E)
+========
+
+ snoop(E)
diff --git a/doc/sefun/query_wiz_grp b/doc/sefun/query_wiz_grp
index c45cfe1..fe01fbd 100644
--- a/doc/sefun/query_wiz_grp
+++ b/doc/sefun/query_wiz_grp
@@ -1,15 +1,34 @@
-FUNKTION:
- query_wiz_grp(string wiz)
- query_wiz_grp(object wiz)
-ARGUMENTE:
- wiz - Spieler, dessen Magierlevelgruppe ermittelt werden soll
+query_wiz_grp()
+***************
-BESCHREIBUNG:
- Diese Funktion ermittelt die Magiergruppe, der der Spieler wiz angehoert.
-RUECKGABEWERT:
- Die Magierlevelgruppe des Spielers.
+FUNKTION
+========
-SIEHE AUCH:
- /secure/wizlevels.h
+ 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/sefun/query_wiz_level b/doc/sefun/query_wiz_level
index 03e89cb..3645035 100644
--- a/doc/sefun/query_wiz_level
+++ b/doc/sefun/query_wiz_level
@@ -1,43 +1,70 @@
-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.
+query_wiz_level()
+*****************
-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.
+FUNKTION
+========
-BEMERKUNGEN:
- Wird als Parameter ein String mit einem Spielernamen uebergeben, so
- kann auch der Magierlevel eines nicht eingeloggten Spielers heraus-
- gefunden werden.
+ int query_wiz_level(object ob)
+ int query_wiz_level(string ob)
-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
+ARGUMENTE
+=========
-LETZTE AeNDERUNG:
+ 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/sefun/read_data b/doc/sefun/read_data
index b0707ac..1756890 100644
--- a/doc/sefun/read_data
+++ b/doc/sefun/read_data
@@ -1,18 +1,34 @@
+
+read_data()
+***********
+
+
SYNOPSIS
- string read_data(string file, int start, int anzahl)
+========
+
+ 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.
+============
+
+ 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.
+========
+
+ # 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)
+==========
+
+ write_data()
+ read_file(E), write_file(E), read_bytes(E), write_file(E)
diff --git a/doc/sefun/replace_personal b/doc/sefun/replace_personal
index 2a18dc7..3804be3 100644
--- a/doc/sefun/replace_personal
+++ b/doc/sefun/replace_personal
@@ -1,84 +1,113 @@
-FUNKTION:
- varargs string replace_personal(string str, mixed *obs [, int caps]);
-DEFINIERT IN:
- /secure/simul_efun.c
+replace_personal()
+******************
-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".
+FUNKTION
+========
-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:
+ varargs string replace_personal(string str, mixed *obs [, int caps]);
- 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!"
+DEFINIERT IN
+============
-SIEHE AUCH:
- AddCmd(L)
+ /secure/simul_efun.c
-05. September 2015, Arathorn
+
+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/sefun/restore_object b/doc/sefun/restore_object
index eac5e01..631252d 100644
--- a/doc/sefun/restore_object
+++ b/doc/sefun/restore_object
@@ -1,18 +1,31 @@
+
+restore_object()
+****************
+
+
SYNOPSIS
- mixed restore_object(string name);
+========
+
+ 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.
+ 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
+==========
+ save_object(E), restore_object(E), save_value(E)
+
+29.01.2017, Zesstra
diff --git a/doc/sefun/save_object b/doc/sefun/save_object
index 9614685..fc8175f 100644
--- a/doc/sefun/save_object
+++ b/doc/sefun/save_object
@@ -1,22 +1,35 @@
+
+save_object()
+*************
+
+
SYNOPSIS
- mixed save_object(string name);
+========
+
+ 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.
+============
+
+ 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
+==========
+ save_object(E), restore_object(E), save_value(E)
+
+29.01.2017, Zesstra
diff --git a/doc/sefun/send_room b/doc/sefun/send_room
index 24b05fa..7ddf43d 100644
--- a/doc/sefun/send_room
+++ b/doc/sefun/send_room
@@ -1,30 +1,42 @@
-FUNKTION:
+
+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)
+ 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.
+BESCHREIBUNG
+============
- 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.
+ Sendet msg an alle Objekte in room durch Aufruf von ReceiveMsg() mit
+ den uebergebenen Argumenten.
+ Zur Bedeutung der Argumente siehe Manpage von ReceiveMsg().
- 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.
+ Wenn das Raumobjekt mit seinem Namen angegeben ist, wird das Objekt
+ unter diesem Namen gesucht und und geladen, falls notwendig.
- Letztendlich ist die sefun vergleichbar zu tell_room().
+ 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)
+==========
+
+ ReceiveMsg(L)
+ tell_object(E), tell_room(E), say(E), write(E)
13.03.2016, Zesstra
-
diff --git a/doc/sefun/set_heart_beat b/doc/sefun/set_heart_beat
index 837759e..a304181 100644
--- a/doc/sefun/set_heart_beat
+++ b/doc/sefun/set_heart_beat
@@ -1,23 +1,41 @@
+
+set_heart_beat()
+****************
+
+
SYNOPSIS
- int set_heart_beat(int flag);
+========
+
+ 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.
+ 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.
- Das Abschalten eines bereits abgeschalteten Heartbeats (und umgekehrt
- das Einschalten eines bereits eingeschalteten Heartbeats) zaehlt
- als Fehler.
+
+
+ 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
+===========
+
+ __HEARTBEAT_INTERVAL__ ist in MG = 2 Sekunden
+
SIEHE AUCH
- heart_beat(A), call_out(E)
+==========
+
+ heart_beat(A), call_out(E)
diff --git a/doc/sefun/set_light b/doc/sefun/set_light
index 62390c4..b9dfc9c 100644
--- a/doc/sefun/set_light
+++ b/doc/sefun/set_light
@@ -1,17 +1,32 @@
-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.
+set_light()
+***********
-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.
+
+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/sefun/set_living_name b/doc/sefun/set_living_name
index 360a3ce..e588e6e 100644
--- a/doc/sefun/set_living_name
+++ b/doc/sefun/set_living_name
@@ -1,25 +1,41 @@
-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.
+set_living_name()
+*****************
- 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.
+SYNOPSIS
+========
- Ein Objekt kann nur einen Namen haben, mit dem es per find_living()
- gesucht werden kann.
+ void set_living_name(string name)
-SIEHE AUCH:
- find_living(E), find_livings(E), find_player(E), enable_commands(E)
-LETZTE AeNDERNG:
+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/sefun/set_object_heart_beat b/doc/sefun/set_object_heart_beat
index a7ba4ef..caecca2 100644
--- a/doc/sefun/set_object_heart_beat
+++ b/doc/sefun/set_object_heart_beat
@@ -1,15 +1,34 @@
-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?
+set_object_heart_beat()
+***********************
-BESCHREIBUNG:
- Der heart_beat des Objektes wird ein- (on=1) oder aus- (on=0) geschaltet.
-RUECKGABEWERT:
- 1, wenn das Setzen geklappt hat, ansonsten 0.
+FUNKTION
+========
-SIEHE AUCH:
- set_heart_beat(E), heart_beat(L), call_out(E)
+ 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/sefun/sha1 b/doc/sefun/sha1
index 00bb6cc..ef3b10e 100644
--- a/doc/sefun/sha1
+++ b/doc/sefun/sha1
@@ -1,22 +1,44 @@
+
+sha1()
+******
+
+
DEPRECATED
+==========
+
+
SYNOPSIS
- string sha1 (string arg)
- string sha1 (int * arg)
+========
+
+ 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).
+============
+
+ 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' })
+ 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.
+=======
+
+ Eingefuehrt in LDMud 3.3.523.
+ LDMud 3.3.712 fuehrte Zaehlenarrays als Argument ein.
+
SIEHE AUCH
- crypt(E), md5(E)
+==========
+
+ crypt(E), md5(E)
diff --git a/doc/sefun/shadow b/doc/sefun/shadow
index 9309dea..2b7032c 100644
--- a/doc/sefun/shadow
+++ b/doc/sefun/shadow
@@ -1,143 +1,162 @@
-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
+shadow()
+********
- // 3 Objekte beschatten in Hierarchie (liegt auch im Pfad)
- --- aa.c ---
- void fun() {
- printf("%O [a] fun()\n", this_object());
- }
+FUNKTION
+========
- void fun3() {
- printf("%O [a] fun3()\n", this_object());
- }
+ object shadow(object ob, int flag)
- --- 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();
- }
+ARGUMENTE
+=========
- void do_shadow(object target) { shadow(target, 1); }
+ object ob - das vom shadow betroffene Objekt
+ int flag - 0 fuer eine Shadow-Existenzabfrage
+ 1 fuer Shadow durch previous_object()
- --- 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());
- }
+BESCHREIBUNG
+============
- void do_shadow(object target) { shadow(target, 1); }
+ 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.
- // darauf arbeitender Code
+ 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.
- object a, b, c;
+ Das aufrufende Objekt muss vom Master-Objekt die Erlaubnis haben,
+ als Shadow zu wirken.
- 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");
+ 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
- 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();
+ Beschattet man ein Objekt A mit einem Objekt B und dann das Objekt A
+ zusaetzlich mit einem Objekt C, so wird eine Beschattungshierarchie
+ erstellt:
- // ... und seine Ausgabe:
+ B macht shadow(A, 1)
+ B->A
+ C macht shadow(A, 1)
+ C->B->A
- --- 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.
+BEISPIELE
+=========
-SIEHE AUCH:
- Generell: shadow(E)
- Rechte: query_allow_shadow(M), query_prevent_shadow(L)
- Informationen: query_shadowing(E)
+ // wenn: B beschattet A, dann
+ shadow(find_object(A), 0) == B
-8.Aug 2007 Gloinson
\ No newline at end of file
+
+ // 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/sefun/shout b/doc/sefun/shout
index ead266f..0d38abb 100644
--- a/doc/sefun/shout
+++ b/doc/sefun/shout
@@ -1,69 +1,93 @@
-FUNKTION:
- varargs void shout( string text, mixed where )
-DEFINIERT IN:
- /secure/simul_efun.c
+shout()
+*******
-ARGUMENTE:
- text
- Der Text, der ausgegeben werden soll
- where [optional]
- Wo soll man den Text ueberall hoeren koennen?
+FUNKTION
+========
-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.
+ varargs void shout( string text, mixed where )
- 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.
+DEFINIERT IN
+============
- 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.
+ /secure/simul_efun.c
- 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
+ARGUMENTE
+=========
-BEISPIELE:
- shout( "Du spuerst, wie ein Zittern durch das MorgenGrauen geht.\n" );
- Der allseits bekannte Text wird an alle Spieler im MG ausgegeben.
+ text
+ Der Text, der ausgegeben werden soll
- 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.
+ where [optional]
+ Wo soll man den Text ueberall hoeren koennen?
- 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.
+BESCHREIBUNG
+============
- 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.
+ 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.
-SIEHE AUCH:
- write(), say(), tell_object(), tell_room(), regexp()
+ 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/sefun/time2string b/doc/sefun/time2string
index 4dae719..4acd1a2 100644
--- a/doc/sefun/time2string
+++ b/doc/sefun/time2string
@@ -1,53 +1,75 @@
-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.
+time2string()
+*************
-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"
+FUNKTION
+========
-SIEHE AUCH:
- sprintf(E)
+ 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/sefun/update_actions b/doc/sefun/update_actions
index b28cf9f..b25c07c 100644
--- a/doc/sefun/update_actions
+++ b/doc/sefun/update_actions
@@ -1,38 +1,63 @@
-FUNKTION:
- void update_actions()
-ARGUMENTE:
- keine
+update_actions()
+****************
-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
+FUNKTION
+========
-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).
+ void update_actions()
-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)
+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/sefun/upperstring b/doc/sefun/upperstring
index 665ed16..416c90d 100644
--- a/doc/sefun/upperstring
+++ b/doc/sefun/upperstring
@@ -1,17 +1,39 @@
-FUNKTION:
- string upperstring(string str)
-ARGUMENTE:
- str - Der umzuwandelnde String.
+upperstring()
+*************
-BESCHREIBUNG:
- Alle Kleinbuchstaben in str werden in Grossbuchstaben umgewandelt.
-RUECKGABEWERT:
- Der umgewandelte String.
+FUNKTION
+========
-BEISPIELE:
- s = upperstring( "Na, Sterblicher!\n") => s = "NA, STERBLICHER!\n"
+ string upperstring(string str)
-SIEHE AUCH:
- lowerstring(E), lower_case(E), capitalize(E)
+
+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/sefun/uptime b/doc/sefun/uptime
index ee7a536..4c007a3 100644
--- a/doc/sefun/uptime
+++ b/doc/sefun/uptime
@@ -1,16 +1,37 @@
-FUNKTION:
- string uptime()
-ARGUMENTE:
- keine
+uptime()
+********
-BESCHREIBUNG:
- Liefert die aktuelle Uptime des MorgenGrauens.
-RUECKGABEWERT:
- Die Uptime als Zeitstring.
+FUNKTION
+========
-BEISPIELE:
- ut = uptime() => ut = "14 Tage, 9 Stunden, 3 Minuten und 7 Sekunden."
+ string uptime()
-SIEHE AUCH:
+
+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/sefun/wizlist b/doc/sefun/wizlist
index a2ba7bd..f81b9b8 100644
--- a/doc/sefun/wizlist
+++ b/doc/sefun/wizlist
@@ -1,66 +1,84 @@
-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>.
+wizlist()
+*********
- 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.
+SYNOPSIS
+========
- 2. WL_COMMANDS
- Anzahl der diesem Objekt zugeordneten commands.
+ varargs void wizlist(string name, int sortkey )
- 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.
+DESCRIPTION
+===========
- 5. WL_TOTAL_GIGACOST (rechts in der eckigen Klammer)
- Anzahl der insgesamt verbrauchten eval ticks in Giga-Ticks.
- Nicht zeitlich gewichtet.
+ 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>.
- 6. WL_HEART_BEATS
- Anzahl der ausgeloesten heart beats.
-
- 7. WL_ARRAY_TOTAL
+ Die Liste ist dabei folgendermassen aufgebaut:
- 8. WL_MAPPING_TOTAL
+ 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.
-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.
+ 2. WL_COMMANDS
+ Anzahl der diesem Objekt zugeordneten commands.
- Wird als name "TOP100" angegeben, wird die Top-100-Liste ausgegeben.
+ 3. WL_COMMANDS * 100 / total_cmd
+ Prozentualer Anteil an den gesamt verbrauchten commands.
- Wird als name "ALL" angegeben, wird die vollstaendige Liste aus-
- gegeben.
+ 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.
- 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.
+ 5. WL_TOTAL_GIGACOST (rechts in der eckigen Klammer)
+ Anzahl der insgesamt verbrauchten eval ticks in Giga-Ticks.
+ Nicht zeitlich gewichtet.
- > xeval wizlist("ALL", WL_EVAL_COST)
+ 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
+SEE ALSO
+========
+ wizlist_info(E)
+
+
+LAST UPDATED
+============
+
+ 09.05.2015, Zesstra
diff --git a/doc/sefun/wizlist_info b/doc/sefun/wizlist_info
index 2a5c127..0c86434 100644
--- a/doc/sefun/wizlist_info
+++ b/doc/sefun/wizlist_info
@@ -1,39 +1,58 @@
-GESCHUETZT
-SYNOPSIS
- #include <sys/wizlist.h>
- *mixed wizlist_info();
+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:
+ Liefert ein Array mit Eintraegen aus der Wizlist (der internen
+ Magierliste). Die Benutzung muss durch das Masterobjekt erlaubt
+ werden.
- 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
+ Das Resultat ist ein Array mit einem Eintrag fuer jeden Magier (uid).
+ Jeder Eintrag enthaelt wiederum ein Array mit folgenden Elementen:
- Die "gewichteten" Werte verfallen pro Stunde um 10%.
+ 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.
+===========
+
+ 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)
+==========
+
+ privilege_violation(M), set_extra_wizinfo_size(E),
+ get_extra_wizinfo(E), set_extra_wizinfo(E)
diff --git a/doc/sefun/write_data b/doc/sefun/write_data
index 5a205d5..b8f0d4f 100644
--- a/doc/sefun/write_data
+++ b/doc/sefun/write_data
@@ -1,23 +1,39 @@
+
+write_data()
+************
+
+
SYNOPSIS
- string write_data(string file, int start, int anzahl)
+========
+
+ 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.
+ 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.
+========
+
+ # 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)
+==========
+
+ read_data()
+ read_file(E), write_file(E), read_bytes(E), write_file(E)
diff --git a/doc/sphinx/man/index b/doc/sphinx/man/index
new file mode 100644
index 0000000..b2693f9
--- /dev/null
+++ b/doc/sphinx/man/index
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..63c3862
--- /dev/null
+++ b/doc/sphinx/man/lfun-liste
@@ -0,0 +1,871 @@
+
+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
new file mode 100644
index 0000000..2018524
--- /dev/null
+++ b/doc/sphinx/man/lfun.index
@@ -0,0 +1,20 @@
+
+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
new file mode 100644
index 0000000..29c83c1
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddAction
@@ -0,0 +1,104 @@
+
+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
new file mode 100644
index 0000000..a96a5e5
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddAdjective
@@ -0,0 +1,62 @@
+
+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
new file mode 100644
index 0000000..59bb9b1
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddAmount
@@ -0,0 +1,44 @@
+
+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
new file mode 100644
index 0000000..fee72e3
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddClass
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..088da28
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddCmd
@@ -0,0 +1,244 @@
+
+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
new file mode 100644
index 0000000..ec8ff17
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddCmd_bsp
@@ -0,0 +1,382 @@
+
+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
new file mode 100644
index 0000000..5b33e14
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddDefender
@@ -0,0 +1,50 @@
+
+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
new file mode 100644
index 0000000..951b48a
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddDetail
@@ -0,0 +1,110 @@
+
+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
new file mode 100644
index 0000000..4d722ec
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddDrink
@@ -0,0 +1,18 @@
+
+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
new file mode 100644
index 0000000..384975f
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddExit
@@ -0,0 +1,114 @@
+
+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
new file mode 100644
index 0000000..a8bf488
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddExp
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..7436f7e
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddExtraLook
@@ -0,0 +1,130 @@
+
+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
new file mode 100644
index 0000000..5875ee2
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddFixedObject
@@ -0,0 +1,74 @@
+
+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
new file mode 100644
index 0000000..b870a5e
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddFood
@@ -0,0 +1,18 @@
+
+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
new file mode 100644
index 0000000..cd0b25e
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddFuel
@@ -0,0 +1,51 @@
+
+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
new file mode 100644
index 0000000..5ba6cf1
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddFun
@@ -0,0 +1,85 @@
+
+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
new file mode 100644
index 0000000..8c2aa4e
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddId
@@ -0,0 +1,75 @@
+
+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
new file mode 100644
index 0000000..759a300
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddInfo
@@ -0,0 +1,243 @@
+
+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
new file mode 100644
index 0000000..222b24d
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddItem
@@ -0,0 +1,184 @@
+
+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
new file mode 100644
index 0000000..874e55c
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddKnownPotion
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..7f90d82
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddMaterial
@@ -0,0 +1,100 @@
+
+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
new file mode 100644
index 0000000..787e718
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddMiniQuest
@@ -0,0 +1,71 @@
+
+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
new file mode 100644
index 0000000..b9e16b2
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddMoney
@@ -0,0 +1,92 @@
+
+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
new file mode 100644
index 0000000..9faad47
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddMsg
@@ -0,0 +1,62 @@
+
+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
new file mode 100644
index 0000000..ae2df8b
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddPlant
@@ -0,0 +1,84 @@
+
+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
new file mode 100644
index 0000000..8d6d249
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddPluralId
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..f4839e6
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddPursuer
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..7f36aa4
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddReadDetail
@@ -0,0 +1,102 @@
+
+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
new file mode 100644
index 0000000..b8a5ad8
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddResistanceModifier
@@ -0,0 +1,75 @@
+
+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
new file mode 100644
index 0000000..f4aeb68
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddRoomCmd
@@ -0,0 +1,23 @@
+
+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
new file mode 100644
index 0000000..aa700c1
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddRoomMessage
@@ -0,0 +1,103 @@
+
+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
new file mode 100644
index 0000000..265fa8a
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddRoute
@@ -0,0 +1,114 @@
+
+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
new file mode 100644
index 0000000..c45199e
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddSingularId
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..2623f98
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddSmells
@@ -0,0 +1,92 @@
+
+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
new file mode 100644
index 0000000..b14b976
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddSounds
@@ -0,0 +1,82 @@
+
+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
new file mode 100644
index 0000000..3405eec
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddSpecialDetail
@@ -0,0 +1,87 @@
+
+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
new file mode 100644
index 0000000..2f16c17
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddSpecialExit
@@ -0,0 +1,82 @@
+
+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
new file mode 100644
index 0000000..efc3067
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddSpecialInfo
@@ -0,0 +1,88 @@
+
+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
new file mode 100644
index 0000000..1661f8c
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddSpell
@@ -0,0 +1,173 @@
+
+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
new file mode 100644
index 0000000..01d46b6
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddToMenu
@@ -0,0 +1,271 @@
+
+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
new file mode 100644
index 0000000..6ca61e8
--- /dev/null
+++ b/doc/sphinx/man/lfun/AddTouchDetail
@@ -0,0 +1,90 @@
+
+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
new file mode 100644
index 0000000..6511189
--- /dev/null
+++ b/doc/sphinx/man/lfun/AllGroups
@@ -0,0 +1,36 @@
+
+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
new file mode 100644
index 0000000..57d1f6d
--- /dev/null
+++ b/doc/sphinx/man/lfun/AllMaterials
@@ -0,0 +1,36 @@
+
+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
new file mode 100644
index 0000000..139a670
--- /dev/null
+++ b/doc/sphinx/man/lfun/AssocMember
@@ -0,0 +1,74 @@
+
+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
new file mode 100644
index 0000000..08a0c20
--- /dev/null
+++ b/doc/sphinx/man/lfun/Attack
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..a64f328
--- /dev/null
+++ b/doc/sphinx/man/lfun/BecomesNetAlive
@@ -0,0 +1,68 @@
+
+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
new file mode 100644
index 0000000..8938d13
--- /dev/null
+++ b/doc/sphinx/man/lfun/BecomesNetDead
@@ -0,0 +1,67 @@
+
+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
new file mode 100644
index 0000000..b86d33a
--- /dev/null
+++ b/doc/sphinx/man/lfun/CannotSee
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..507bd68
--- /dev/null
+++ b/doc/sphinx/man/lfun/ChangeMiniQuest
@@ -0,0 +1,72 @@
+
+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
new file mode 100644
index 0000000..c3d010e
--- /dev/null
+++ b/doc/sphinx/man/lfun/ChangeReputation
@@ -0,0 +1,72 @@
+
+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
new file mode 100644
index 0000000..a021a58
--- /dev/null
+++ b/doc/sphinx/man/lfun/CheckFindRestrictions
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..2296ab8
--- /dev/null
+++ b/doc/sphinx/man/lfun/CheckLightType
@@ -0,0 +1,110 @@
+
+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
new file mode 100644
index 0000000..bcf64ca
--- /dev/null
+++ b/doc/sphinx/man/lfun/CheckResistance
@@ -0,0 +1,37 @@
+
+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
new file mode 100644
index 0000000..74f6220
--- /dev/null
+++ b/doc/sphinx/man/lfun/CheckSensitiveAttack
@@ -0,0 +1,54 @@
+
+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
new file mode 100644
index 0000000..ac9d3fe
--- /dev/null
+++ b/doc/sphinx/man/lfun/CheckSpellFatigue
@@ -0,0 +1,85 @@
+
+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
new file mode 100644
index 0000000..869d298
--- /dev/null
+++ b/doc/sphinx/man/lfun/ClearRingBuffer
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..5a919ce
--- /dev/null
+++ b/doc/sphinx/man/lfun/Configure
@@ -0,0 +1,102 @@
+
+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
new file mode 100644
index 0000000..874753b
--- /dev/null
+++ b/doc/sphinx/man/lfun/ConvMaterialList
@@ -0,0 +1,65 @@
+
+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
new file mode 100644
index 0000000..e10b671
--- /dev/null
+++ b/doc/sphinx/man/lfun/CreateRingBuffer
@@ -0,0 +1,70 @@
+
+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
new file mode 100644
index 0000000..2c7736a
--- /dev/null
+++ b/doc/sphinx/man/lfun/CustomizeObject
@@ -0,0 +1,84 @@
+
+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
new file mode 100644
index 0000000..b36061b
--- /dev/null
+++ b/doc/sphinx/man/lfun/Damage
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..f47d548
--- /dev/null
+++ b/doc/sphinx/man/lfun/DeAssocMember
@@ -0,0 +1,71 @@
+
+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
new file mode 100644
index 0000000..d7a7f91
--- /dev/null
+++ b/doc/sphinx/man/lfun/DeclAdj
@@ -0,0 +1,68 @@
+
+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
new file mode 100644
index 0000000..aa53945
--- /dev/null
+++ b/doc/sphinx/man/lfun/Defend
@@ -0,0 +1,175 @@
+
+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
new file mode 100644
index 0000000..1683b3f
--- /dev/null
+++ b/doc/sphinx/man/lfun/DefendFunc
@@ -0,0 +1,107 @@
+
+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
new file mode 100644
index 0000000..21d41ac
--- /dev/null
+++ b/doc/sphinx/man/lfun/DefendInfo
@@ -0,0 +1,216 @@
+
+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
new file mode 100644
index 0000000..f0386f2
--- /dev/null
+++ b/doc/sphinx/man/lfun/DefendOther
@@ -0,0 +1,107 @@
+
+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
new file mode 100644
index 0000000..9feb25f
--- /dev/null
+++ b/doc/sphinx/man/lfun/Defend_bsp
@@ -0,0 +1,155 @@
+
+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
new file mode 100644
index 0000000..f01755b
--- /dev/null
+++ b/doc/sphinx/man/lfun/DeleteSpellFatigue
@@ -0,0 +1,55 @@
+
+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
new file mode 100644
index 0000000..2d1bd1e
--- /dev/null
+++ b/doc/sphinx/man/lfun/DeleteTimedAttrModifier
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..9046a0e
--- /dev/null
+++ b/doc/sphinx/man/lfun/DiscoverDoor
@@ -0,0 +1,54 @@
+
+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
new file mode 100644
index 0000000..e29427d
--- /dev/null
+++ b/doc/sphinx/man/lfun/DistributeExp
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..695856a
--- /dev/null
+++ b/doc/sphinx/man/lfun/DoDecay
@@ -0,0 +1,69 @@
+
+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
new file mode 100644
index 0000000..671f9c7
--- /dev/null
+++ b/doc/sphinx/man/lfun/DoDecayMessage
@@ -0,0 +1,54 @@
+
+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
new file mode 100644
index 0000000..56e53d3
--- /dev/null
+++ b/doc/sphinx/man/lfun/DoUnwear
@@ -0,0 +1,55 @@
+
+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
new file mode 100644
index 0000000..d003bfc
--- /dev/null
+++ b/doc/sphinx/man/lfun/DoUnwield
@@ -0,0 +1,54 @@
+
+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
new file mode 100644
index 0000000..e253290
--- /dev/null
+++ b/doc/sphinx/man/lfun/DoWear
@@ -0,0 +1,64 @@
+
+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
new file mode 100644
index 0000000..6e6c06c
--- /dev/null
+++ b/doc/sphinx/man/lfun/DoWield
@@ -0,0 +1,63 @@
+
+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
new file mode 100644
index 0000000..b799698
--- /dev/null
+++ b/doc/sphinx/man/lfun/DoorIsKnown
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..9d8d7e0
--- /dev/null
+++ b/doc/sphinx/man/lfun/Dump
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..bf3853c
--- /dev/null
+++ b/doc/sphinx/man/lfun/EnemyPresent
@@ -0,0 +1,34 @@
+
+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
new file mode 100644
index 0000000..0ebc7f0
--- /dev/null
+++ b/doc/sphinx/man/lfun/Enter
@@ -0,0 +1,64 @@
+
+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
new file mode 100644
index 0000000..7daf07c
--- /dev/null
+++ b/doc/sphinx/man/lfun/EvalArmour
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..395a0a1
--- /dev/null
+++ b/doc/sphinx/man/lfun/EvalWeapon
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..cc0b109
--- /dev/null
+++ b/doc/sphinx/man/lfun/ExtraAttack
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..32a7f2b
--- /dev/null
+++ b/doc/sphinx/man/lfun/FilterArmours
@@ -0,0 +1,99 @@
+
+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
new file mode 100644
index 0000000..a7e1d01
--- /dev/null
+++ b/doc/sphinx/man/lfun/FilterClothing
@@ -0,0 +1,80 @@
+
+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
new file mode 100644
index 0000000..10a5d80
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindBestArmours
@@ -0,0 +1,64 @@
+
+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
new file mode 100644
index 0000000..1aaeb0d
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindBestWeapon
@@ -0,0 +1,59 @@
+
+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
new file mode 100644
index 0000000..5ea712d
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindDistantEnemyVictim
@@ -0,0 +1,55 @@
+
+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
new file mode 100644
index 0000000..b94e048
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindDistantGroup
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..efb3354
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindDistantGroups
@@ -0,0 +1,85 @@
+
+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
new file mode 100644
index 0000000..c5a81a6
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindEnemyVictim
@@ -0,0 +1,47 @@
+
+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
new file mode 100644
index 0000000..455cf89
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindFarEnemyVictim
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..112c76f
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindGroup
@@ -0,0 +1,98 @@
+
+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
new file mode 100644
index 0000000..b0104ee
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindGroupN
@@ -0,0 +1,67 @@
+
+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
new file mode 100644
index 0000000..e4c297b
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindGroupP
@@ -0,0 +1,68 @@
+
+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
new file mode 100644
index 0000000..4bd0458
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindNearEnemyVictim
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..5d8cae1
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindPotion
@@ -0,0 +1,74 @@
+
+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
new file mode 100644
index 0000000..5fa6776
--- /dev/null
+++ b/doc/sphinx/man/lfun/FindRangedTarget
@@ -0,0 +1,63 @@
+
+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
new file mode 100644
index 0000000..995cf26
--- /dev/null
+++ b/doc/sphinx/man/lfun/Flee
@@ -0,0 +1,83 @@
+
+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
new file mode 100644
index 0000000..c876b21
--- /dev/null
+++ b/doc/sphinx/man/lfun/FreeHands
@@ -0,0 +1,60 @@
+
+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
new file mode 100644
index 0000000..3896ac5
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetAquarium
@@ -0,0 +1,59 @@
+
+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
new file mode 100644
index 0000000..7e5a092
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetDetail
@@ -0,0 +1,90 @@
+
+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
new file mode 100644
index 0000000..68beb0d
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetDoorsMapping
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..e288250
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetEnemies
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..a235b1f
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetExits
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..30db195
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetFValue
@@ -0,0 +1,47 @@
+
+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
new file mode 100644
index 0000000..25650fb
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetFValueO
@@ -0,0 +1,85 @@
+
+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
new file mode 100644
index 0000000..adc6a19
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetFactor
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..8c765d7
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetGroupMembers
@@ -0,0 +1,60 @@
+
+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
new file mode 100644
index 0000000..ba6c4c4
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetInfoArr
@@ -0,0 +1,55 @@
+
+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
new file mode 100644
index 0000000..e25e991
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetMatMembership
@@ -0,0 +1,79 @@
+
+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
new file mode 100644
index 0000000..ee982b7
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetOffset
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..92543f0
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetOwner
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..ccd0f68
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetPhiolenInfos
@@ -0,0 +1,122 @@
+
+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
new file mode 100644
index 0000000..b27d053
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetReputation
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..134bd2c
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetReputations
@@ -0,0 +1,47 @@
+
+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
new file mode 100644
index 0000000..29eea03
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetValue
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..e9a7522
--- /dev/null
+++ b/doc/sphinx/man/lfun/GetValueO
@@ -0,0 +1,47 @@
+
+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
new file mode 100644
index 0000000..dd5676f
--- /dev/null
+++ b/doc/sphinx/man/lfun/Gildenproperties
@@ -0,0 +1,186 @@
+
+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
new file mode 100644
index 0000000..d208dbd
--- /dev/null
+++ b/doc/sphinx/man/lfun/GiveMiniQuest
@@ -0,0 +1,68 @@
+
+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
new file mode 100644
index 0000000..daedc6c
--- /dev/null
+++ b/doc/sphinx/man/lfun/GiveQuest
@@ -0,0 +1,86 @@
+
+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
new file mode 100644
index 0000000..7b819be
--- /dev/null
+++ b/doc/sphinx/man/lfun/GroupName
@@ -0,0 +1,87 @@
+
+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
new file mode 100644
index 0000000..88da3c9
--- /dev/null
+++ b/doc/sphinx/man/lfun/GuardExit
@@ -0,0 +1,111 @@
+
+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
new file mode 100644
index 0000000..2fb45e8
--- /dev/null
+++ b/doc/sphinx/man/lfun/Halt
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..c832f00
--- /dev/null
+++ b/doc/sphinx/man/lfun/HasMiniQuest
@@ -0,0 +1,59 @@
+
+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
new file mode 100644
index 0000000..2fb9b79
--- /dev/null
+++ b/doc/sphinx/man/lfun/HitFunc
@@ -0,0 +1,94 @@
+
+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
new file mode 100644
index 0000000..9f55541
--- /dev/null
+++ b/doc/sphinx/man/lfun/Identify
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..73fef03
--- /dev/null
+++ b/doc/sphinx/man/lfun/InFight
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..82de3c9
--- /dev/null
+++ b/doc/sphinx/man/lfun/InList
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..4967510
--- /dev/null
+++ b/doc/sphinx/man/lfun/InformAlcoholEffect
@@ -0,0 +1,65 @@
+
+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
new file mode 100644
index 0000000..d6a401e
--- /dev/null
+++ b/doc/sphinx/man/lfun/InformDefend
@@ -0,0 +1,81 @@
+
+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
new file mode 100644
index 0000000..7e7b804
--- /dev/null
+++ b/doc/sphinx/man/lfun/InformRowChange
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..01e9886
--- /dev/null
+++ b/doc/sphinx/man/lfun/InformUnwear
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..1f10e72
--- /dev/null
+++ b/doc/sphinx/man/lfun/InformUnwield
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..6860633
--- /dev/null
+++ b/doc/sphinx/man/lfun/InformWear
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..0c14c2a
--- /dev/null
+++ b/doc/sphinx/man/lfun/InformWield
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..84885db
--- /dev/null
+++ b/doc/sphinx/man/lfun/InsertEnemy
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..b25843d
--- /dev/null
+++ b/doc/sphinx/man/lfun/InsertEnemyTeam
@@ -0,0 +1,66 @@
+
+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
new file mode 100644
index 0000000..534db19
--- /dev/null
+++ b/doc/sphinx/man/lfun/InsertSensitiveObject
@@ -0,0 +1,68 @@
+
+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
new file mode 100644
index 0000000..2d9f3eb
--- /dev/null
+++ b/doc/sphinx/man/lfun/InternalModifyAttack
@@ -0,0 +1,58 @@
+
+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
new file mode 100644
index 0000000..3015534
--- /dev/null
+++ b/doc/sphinx/man/lfun/InternalModifyDefend
@@ -0,0 +1,50 @@
+
+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
new file mode 100644
index 0000000..a7e5daf
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsArmour
@@ -0,0 +1,55 @@
+
+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
new file mode 100644
index 0000000..08f0125
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsBottle
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..c51f3f6
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsClothing
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..45fb1fc
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsEnemy
@@ -0,0 +1,50 @@
+
+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
new file mode 100644
index 0000000..34d142f
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsEqual
@@ -0,0 +1,58 @@
+
+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
new file mode 100644
index 0000000..3cccc05
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsPlayerCorpse
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..61ce904
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsRoom
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..1880cc9
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsTeamLeader
@@ -0,0 +1,68 @@
+
+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
new file mode 100644
index 0000000..584dc13
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsTeamMove
@@ -0,0 +1,60 @@
+
+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
new file mode 100644
index 0000000..230f09e
--- /dev/null
+++ b/doc/sphinx/man/lfun/IsUnit
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..1125345
--- /dev/null
+++ b/doc/sphinx/man/lfun/Kill
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..caab276
--- /dev/null
+++ b/doc/sphinx/man/lfun/LearnSkill
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..fef5e6f
--- /dev/null
+++ b/doc/sphinx/man/lfun/Leave
@@ -0,0 +1,64 @@
+
+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
new file mode 100644
index 0000000..6c31eed
--- /dev/null
+++ b/doc/sphinx/man/lfun/LimitAbility
@@ -0,0 +1,67 @@
+
+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
new file mode 100644
index 0000000..1b4e61e
--- /dev/null
+++ b/doc/sphinx/man/lfun/MaterialGroup
@@ -0,0 +1,64 @@
+
+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
new file mode 100644
index 0000000..228f7a8
--- /dev/null
+++ b/doc/sphinx/man/lfun/MaterialList
@@ -0,0 +1,96 @@
+
+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
new file mode 100644
index 0000000..782a9f7
--- /dev/null
+++ b/doc/sphinx/man/lfun/MaterialName
@@ -0,0 +1,96 @@
+
+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
new file mode 100644
index 0000000..1df06ea
--- /dev/null
+++ b/doc/sphinx/man/lfun/MayAddObject
@@ -0,0 +1,55 @@
+
+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
new file mode 100644
index 0000000..bc8e06d
--- /dev/null
+++ b/doc/sphinx/man/lfun/MayAddWeight
@@ -0,0 +1,72 @@
+
+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
new file mode 100644
index 0000000..bee1d46
--- /dev/null
+++ b/doc/sphinx/man/lfun/Message
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..432a362
--- /dev/null
+++ b/doc/sphinx/man/lfun/ModifyQuestTime
@@ -0,0 +1,66 @@
+
+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
new file mode 100644
index 0000000..70c33ba
--- /dev/null
+++ b/doc/sphinx/man/lfun/ModifySkill
@@ -0,0 +1,98 @@
+
+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
new file mode 100644
index 0000000..1b4fe40
--- /dev/null
+++ b/doc/sphinx/man/lfun/ModifySkillAttribute
@@ -0,0 +1,133 @@
+
+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
new file mode 100644
index 0000000..c504209
--- /dev/null
+++ b/doc/sphinx/man/lfun/More
@@ -0,0 +1,80 @@
+
+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
new file mode 100644
index 0000000..3b8801d
--- /dev/null
+++ b/doc/sphinx/man/lfun/NPC_Killed_by
@@ -0,0 +1,28 @@
+
+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
new file mode 100644
index 0000000..c534be5
--- /dev/null
+++ b/doc/sphinx/man/lfun/NewDoor
@@ -0,0 +1,252 @@
+
+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
new file mode 100644
index 0000000..4b6013a
--- /dev/null
+++ b/doc/sphinx/man/lfun/NoParaObjects
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..31e02e9
--- /dev/null
+++ b/doc/sphinx/man/lfun/NotifyDestruct
@@ -0,0 +1,66 @@
+
+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
new file mode 100644
index 0000000..fa2f2ac
--- /dev/null
+++ b/doc/sphinx/man/lfun/NotifyInsert
@@ -0,0 +1,47 @@
+
+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
new file mode 100644
index 0000000..fbfc1c3
--- /dev/null
+++ b/doc/sphinx/man/lfun/NotifyLeave
@@ -0,0 +1,47 @@
+
+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
new file mode 100644
index 0000000..18261f8
--- /dev/null
+++ b/doc/sphinx/man/lfun/NotifyMove
@@ -0,0 +1,83 @@
+
+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
new file mode 100644
index 0000000..96678ea
--- /dev/null
+++ b/doc/sphinx/man/lfun/NotifyPlayerDeath
@@ -0,0 +1,99 @@
+
+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
new file mode 100644
index 0000000..2604b77
--- /dev/null
+++ b/doc/sphinx/man/lfun/NotifyRemove
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..09dc168
--- /dev/null
+++ b/doc/sphinx/man/lfun/NotifyTimedAttrModExpired
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..f3c54a4
--- /dev/null
+++ b/doc/sphinx/man/lfun/NotifyXMAttrModLimitViolation
@@ -0,0 +1,35 @@
+
+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
new file mode 100644
index 0000000..feca7bf
--- /dev/null
+++ b/doc/sphinx/man/lfun/Pacify
@@ -0,0 +1,146 @@
+
+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
new file mode 100644
index 0000000..35616de
--- /dev/null
+++ b/doc/sphinx/man/lfun/PayIn
@@ -0,0 +1,73 @@
+
+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
new file mode 100644
index 0000000..0eb8fbf
--- /dev/null
+++ b/doc/sphinx/man/lfun/PlayerQuit
@@ -0,0 +1,37 @@
+
+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
new file mode 100644
index 0000000..12ac650
--- /dev/null
+++ b/doc/sphinx/man/lfun/PresentEnemies
@@ -0,0 +1,95 @@
+
+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
new file mode 100644
index 0000000..003d6c3
--- /dev/null
+++ b/doc/sphinx/man/lfun/PresentEnemyRows
@@ -0,0 +1,60 @@
+
+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
new file mode 100644
index 0000000..c94d129
--- /dev/null
+++ b/doc/sphinx/man/lfun/PresentPosition
@@ -0,0 +1,58 @@
+
+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
new file mode 100644
index 0000000..37e3ab8
--- /dev/null
+++ b/doc/sphinx/man/lfun/PresentRows
@@ -0,0 +1,120 @@
+
+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
new file mode 100644
index 0000000..3af354b
--- /dev/null
+++ b/doc/sphinx/man/lfun/PresentTeamPositions
@@ -0,0 +1,60 @@
+
+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
new file mode 100644
index 0000000..7875918
--- /dev/null
+++ b/doc/sphinx/man/lfun/PresentTeamRows
@@ -0,0 +1,47 @@
+
+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
new file mode 100644
index 0000000..c3de6b1
--- /dev/null
+++ b/doc/sphinx/man/lfun/PreventFollow
@@ -0,0 +1,72 @@
+
+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
new file mode 100644
index 0000000..3635142
--- /dev/null
+++ b/doc/sphinx/man/lfun/PreventInsert
@@ -0,0 +1,71 @@
+
+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
new file mode 100644
index 0000000..fbde29f
--- /dev/null
+++ b/doc/sphinx/man/lfun/PreventInsertLiving
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..24c33d2
--- /dev/null
+++ b/doc/sphinx/man/lfun/PreventLeave
@@ -0,0 +1,57 @@
+
+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
new file mode 100644
index 0000000..20a5844
--- /dev/null
+++ b/doc/sphinx/man/lfun/PreventLeaveLiving
@@ -0,0 +1,58 @@
+
+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
new file mode 100644
index 0000000..920372d
--- /dev/null
+++ b/doc/sphinx/man/lfun/PreventMove
@@ -0,0 +1,109 @@
+
+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
new file mode 100644
index 0000000..27c2d9e
--- /dev/null
+++ b/doc/sphinx/man/lfun/Query
@@ -0,0 +1,108 @@
+
+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
new file mode 100644
index 0000000..cdf7140
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryAllDoors
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..20fcab5
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryArmourByType
@@ -0,0 +1,91 @@
+
+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
new file mode 100644
index 0000000..9c4de60
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryArrived
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..3be5ecc
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryArticle
@@ -0,0 +1,118 @@
+
+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
new file mode 100644
index 0000000..978c6c0
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryAttribute
@@ -0,0 +1,59 @@
+
+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
new file mode 100644
index 0000000..b16d10c
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryAttributeOffset
@@ -0,0 +1,47 @@
+
+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
new file mode 100644
index 0000000..3f728c3
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryBuyFact
@@ -0,0 +1,41 @@
+
+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
new file mode 100644
index 0000000..cecc57c
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryBuyValue
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..7261758
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryCoinsPerUnits
@@ -0,0 +1,57 @@
+
+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
new file mode 100644
index 0000000..812636a
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryDamage
@@ -0,0 +1,61 @@
+
+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
new file mode 100644
index 0000000..fa3fb11
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryDefend
@@ -0,0 +1,68 @@
+
+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
new file mode 100644
index 0000000..3cf4b8d
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryDisguise
@@ -0,0 +1,51 @@
+
+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
new file mode 100644
index 0000000..f606c52
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryDoorKey
@@ -0,0 +1,71 @@
+
+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
new file mode 100644
index 0000000..74f7034
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryDoorStatus
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..aa184cc
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryDu
@@ -0,0 +1,61 @@
+
+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
new file mode 100644
index 0000000..fc00c0e
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryEnemies
@@ -0,0 +1,54 @@
+
+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
new file mode 100644
index 0000000..e12a119
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryFlaw
@@ -0,0 +1,63 @@
+
+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
new file mode 100644
index 0000000..845758f
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryGenderString
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..62d5580
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryGramsPerUnits
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..5101e8d
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryGroupedKeys
@@ -0,0 +1,44 @@
+
+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
new file mode 100644
index 0000000..61cfb04
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryGuest
@@ -0,0 +1,54 @@
+
+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
new file mode 100644
index 0000000..cc42fbc
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryHealInfo
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..94a5367
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryMaterial
@@ -0,0 +1,62 @@
+
+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
new file mode 100644
index 0000000..3365f73
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryMaterialGroup
@@ -0,0 +1,81 @@
+
+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
new file mode 100644
index 0000000..7b5aba2
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryMaxQP
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..775a65c
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryMoney
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..71e65e3
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryName
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..f43d7cc
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryOpenMiniQuestsForPlayer
@@ -0,0 +1,80 @@
+
+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
new file mode 100644
index 0000000..22e9e5f
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryOwn
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..d6f9331
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryPassengers
@@ -0,0 +1,51 @@
+
+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
new file mode 100644
index 0000000..08af6fe
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryPosition
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..90af78a
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryPossPronoun
@@ -0,0 +1,74 @@
+
+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
new file mode 100644
index 0000000..b783174
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryPrayRoom
@@ -0,0 +1,50 @@
+
+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
new file mode 100644
index 0000000..10a8ae0
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryPreferedEnemy
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..39088f9
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryPronoun
@@ -0,0 +1,54 @@
+
+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
new file mode 100644
index 0000000..71c4fdf
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryProp
@@ -0,0 +1,63 @@
+
+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
new file mode 100644
index 0000000..6949e0f
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryProperties
@@ -0,0 +1,54 @@
+
+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
new file mode 100644
index 0000000..338ed77
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryQuest
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..9b93c8d
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryQuestTime
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..246008f
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryRealAttribute
@@ -0,0 +1,47 @@
+
+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
new file mode 100644
index 0000000..4d5a518
--- /dev/null
+++ b/doc/sphinx/man/lfun/QuerySellValue
@@ -0,0 +1,54 @@
+
+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
new file mode 100644
index 0000000..0978df1
--- /dev/null
+++ b/doc/sphinx/man/lfun/QuerySkill
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..fd8666f
--- /dev/null
+++ b/doc/sphinx/man/lfun/QuerySkillAbility
@@ -0,0 +1,47 @@
+
+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
new file mode 100644
index 0000000..1b3a71e
--- /dev/null
+++ b/doc/sphinx/man/lfun/QuerySkillAttribute
@@ -0,0 +1,87 @@
+
+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
new file mode 100644
index 0000000..055815e
--- /dev/null
+++ b/doc/sphinx/man/lfun/QuerySkillAttributeModifier
@@ -0,0 +1,118 @@
+
+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
new file mode 100644
index 0000000..1cb82e8
--- /dev/null
+++ b/doc/sphinx/man/lfun/QuerySkillBonus
@@ -0,0 +1,91 @@
+
+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
new file mode 100644
index 0000000..4442237
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryStorageRoom
@@ -0,0 +1,27 @@
+
+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
new file mode 100644
index 0000000..4d858a8
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryTimedAttrModifier
@@ -0,0 +1,67 @@
+
+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
new file mode 100644
index 0000000..1471010
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryTotalQP
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..ad1e4fa
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryUser
@@ -0,0 +1,77 @@
+
+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
new file mode 100644
index 0000000..649a0b2
--- /dev/null
+++ b/doc/sphinx/man/lfun/QueryValidObject
@@ -0,0 +1,69 @@
+
+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
new file mode 100644
index 0000000..cd1a34d
--- /dev/null
+++ b/doc/sphinx/man/lfun/ReceiveMsg
@@ -0,0 +1,278 @@
+
+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
new file mode 100644
index 0000000..a664b3b
--- /dev/null
+++ b/doc/sphinx/man/lfun/RegisterEvent
@@ -0,0 +1,113 @@
+
+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
new file mode 100644
index 0000000..f8b6a2e
--- /dev/null
+++ b/doc/sphinx/man/lfun/RegisterHelperNPC
@@ -0,0 +1,114 @@
+
+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
new file mode 100644
index 0000000..af33a5c
--- /dev/null
+++ b/doc/sphinx/man/lfun/RegisterHelperObject
@@ -0,0 +1,145 @@
+
+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
new file mode 100644
index 0000000..bd1796f
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveAdjective
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..26b0b79
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveClass
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..6adffbf
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveCmd
@@ -0,0 +1,91 @@
+
+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
new file mode 100644
index 0000000..1dec97a
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveDefender
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..48a0330
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveDetail
@@ -0,0 +1,80 @@
+
+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
new file mode 100644
index 0000000..6854229
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveExit
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..0369992
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveExtraLook
@@ -0,0 +1,65 @@
+
+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
new file mode 100644
index 0000000..22179de
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveFixedObject
@@ -0,0 +1,62 @@
+
+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
new file mode 100644
index 0000000..fdcb916
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveFromMenu
@@ -0,0 +1,55 @@
+
+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
new file mode 100644
index 0000000..bf01ae9
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveFunc
@@ -0,0 +1,113 @@
+
+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
new file mode 100644
index 0000000..efd709d
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveId
@@ -0,0 +1,44 @@
+
+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
new file mode 100644
index 0000000..75485c6
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveInfo
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..a21cdc2
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveItem
@@ -0,0 +1,64 @@
+
+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
new file mode 100644
index 0000000..f7af610
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveKnownPotion
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..23f394a
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemovePluralId
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..cf8f0dc
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemovePursuer
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..495dfe3
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveReadDetail
@@ -0,0 +1,50 @@
+
+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
new file mode 100644
index 0000000..ca14c74
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveResistanceModifier
@@ -0,0 +1,57 @@
+
+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
new file mode 100644
index 0000000..61fb082
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveRoute
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..0678e70
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveSensitiveObject
@@ -0,0 +1,79 @@
+
+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
new file mode 100644
index 0000000..fcf0c3d
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveSingularId
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..5fa69b2
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveSkillAttributeModifier
@@ -0,0 +1,83 @@
+
+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
new file mode 100644
index 0000000..b56fe27
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveSmells
@@ -0,0 +1,57 @@
+
+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
new file mode 100644
index 0000000..4ef4263
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveSounds
@@ -0,0 +1,66 @@
+
+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
new file mode 100644
index 0000000..96a7a39
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveSpecialDetail
@@ -0,0 +1,60 @@
+
+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
new file mode 100644
index 0000000..ee2e8e8
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveSpecialExit
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..4f6ace3
--- /dev/null
+++ b/doc/sphinx/man/lfun/RemoveTouchDetail
@@ -0,0 +1,75 @@
+
+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
new file mode 100644
index 0000000..17c3332
--- /dev/null
+++ b/doc/sphinx/man/lfun/ResizeRingBuffer
@@ -0,0 +1,66 @@
+
+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
new file mode 100644
index 0000000..128807f
--- /dev/null
+++ b/doc/sphinx/man/lfun/RingBufferGet
@@ -0,0 +1,63 @@
+
+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
new file mode 100644
index 0000000..00c046c
--- /dev/null
+++ b/doc/sphinx/man/lfun/RingBufferPut
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..040965e
--- /dev/null
+++ b/doc/sphinx/man/lfun/SearchPath
@@ -0,0 +1,108 @@
+
+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
new file mode 100644
index 0000000..5a05eab
--- /dev/null
+++ b/doc/sphinx/man/lfun/SelectEnemy
@@ -0,0 +1,51 @@
+
+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
new file mode 100644
index 0000000..c390d42
--- /dev/null
+++ b/doc/sphinx/man/lfun/SelectFarEnemy
@@ -0,0 +1,65 @@
+
+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
new file mode 100644
index 0000000..43ba033
--- /dev/null
+++ b/doc/sphinx/man/lfun/SelectNearEnemy
@@ -0,0 +1,69 @@
+
+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
new file mode 100644
index 0000000..d654027
--- /dev/null
+++ b/doc/sphinx/man/lfun/Set
@@ -0,0 +1,174 @@
+
+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
new file mode 100644
index 0000000..90e8a66
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetAttackChats
@@ -0,0 +1,104 @@
+
+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
new file mode 100644
index 0000000..fe5d97b
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetAttr
@@ -0,0 +1,55 @@
+
+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
new file mode 100644
index 0000000..139fc99
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetAttribute
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..8994bd3
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetBuyFact
@@ -0,0 +1,58 @@
+
+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
new file mode 100644
index 0000000..70d312e
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetChats
@@ -0,0 +1,94 @@
+
+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
new file mode 100644
index 0000000..0533275
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetCoinsPerUnits
@@ -0,0 +1,63 @@
+
+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
new file mode 100644
index 0000000..c433c40
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetDoorStatus
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..2c92035
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetEnemies
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..66c1934
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetGramsPerUnits
@@ -0,0 +1,54 @@
+
+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
new file mode 100644
index 0000000..9664be8
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetProp
@@ -0,0 +1,70 @@
+
+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
new file mode 100644
index 0000000..a4ac72a
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetProperties
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..fc72d9b
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetRealAttribute
@@ -0,0 +1,55 @@
+
+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
new file mode 100644
index 0000000..f2c5861
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetSpellFatigue
@@ -0,0 +1,99 @@
+
+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
new file mode 100644
index 0000000..f1d66a5
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetStorageRoom
@@ -0,0 +1,108 @@
+
+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
new file mode 100644
index 0000000..5ab39dd
--- /dev/null
+++ b/doc/sphinx/man/lfun/SetTimedAttrModifier
@@ -0,0 +1,113 @@
+
+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
new file mode 100644
index 0000000..c315632
--- /dev/null
+++ b/doc/sphinx/man/lfun/ShowDoors
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..41599d7
--- /dev/null
+++ b/doc/sphinx/man/lfun/ShowPropList
@@ -0,0 +1,74 @@
+
+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
new file mode 100644
index 0000000..128cea7
--- /dev/null
+++ b/doc/sphinx/man/lfun/SkillResTransfer
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..ba00347
--- /dev/null
+++ b/doc/sphinx/man/lfun/SpellAttack
@@ -0,0 +1,97 @@
+
+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
new file mode 100644
index 0000000..22b038c
--- /dev/null
+++ b/doc/sphinx/man/lfun/SpellDefend
@@ -0,0 +1,71 @@
+
+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
new file mode 100644
index 0000000..ce8fdbd
--- /dev/null
+++ b/doc/sphinx/man/lfun/SpellInform
@@ -0,0 +1,51 @@
+
+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
new file mode 100644
index 0000000..e0b1070
--- /dev/null
+++ b/doc/sphinx/man/lfun/Start
@@ -0,0 +1,44 @@
+
+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
new file mode 100644
index 0000000..e09d9fa
--- /dev/null
+++ b/doc/sphinx/man/lfun/StopHuntFor
@@ -0,0 +1,77 @@
+
+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
new file mode 100644
index 0000000..fca271b
--- /dev/null
+++ b/doc/sphinx/man/lfun/StopHuntText
@@ -0,0 +1,77 @@
+
+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
new file mode 100644
index 0000000..31c2047
--- /dev/null
+++ b/doc/sphinx/man/lfun/SuggestArticle
@@ -0,0 +1,57 @@
+
+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
new file mode 100644
index 0000000..aa18364
--- /dev/null
+++ b/doc/sphinx/man/lfun/SwapRows
@@ -0,0 +1,60 @@
+
+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
new file mode 100644
index 0000000..40d99a2
--- /dev/null
+++ b/doc/sphinx/man/lfun/TakeFlaw
@@ -0,0 +1,100 @@
+
+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
new file mode 100644
index 0000000..216fbbf
--- /dev/null
+++ b/doc/sphinx/man/lfun/TeamFlee
@@ -0,0 +1,60 @@
+
+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
new file mode 100644
index 0000000..5971bfb
--- /dev/null
+++ b/doc/sphinx/man/lfun/TeamMembers
@@ -0,0 +1,58 @@
+
+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
new file mode 100644
index 0000000..2cf1582
--- /dev/null
+++ b/doc/sphinx/man/lfun/TeamPrefix
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..ddddb89
--- /dev/null
+++ b/doc/sphinx/man/lfun/Teleport
@@ -0,0 +1,51 @@
+
+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
new file mode 100644
index 0000000..d1d2b95
--- /dev/null
+++ b/doc/sphinx/man/lfun/TestIgnore
@@ -0,0 +1,88 @@
+
+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
new file mode 100644
index 0000000..c0ec76e
--- /dev/null
+++ b/doc/sphinx/man/lfun/TestIgnoreSimple
@@ -0,0 +1,77 @@
+
+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
new file mode 100644
index 0000000..df9f7b2
--- /dev/null
+++ b/doc/sphinx/man/lfun/TestLimitViolation
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..44dd2e4
--- /dev/null
+++ b/doc/sphinx/man/lfun/TriggerEvent
@@ -0,0 +1,87 @@
+
+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
new file mode 100644
index 0000000..6d9bfb7
--- /dev/null
+++ b/doc/sphinx/man/lfun/UnregisterEvent
@@ -0,0 +1,79 @@
+
+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
new file mode 100644
index 0000000..79c18f6
--- /dev/null
+++ b/doc/sphinx/man/lfun/UnregisterHelperNPC
@@ -0,0 +1,72 @@
+
+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
new file mode 100644
index 0000000..d6242c9
--- /dev/null
+++ b/doc/sphinx/man/lfun/UnregisterHelperObject
@@ -0,0 +1,71 @@
+
+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
new file mode 100644
index 0000000..0ef0a2a
--- /dev/null
+++ b/doc/sphinx/man/lfun/Unwear
@@ -0,0 +1,65 @@
+
+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
new file mode 100644
index 0000000..b3c7d77
--- /dev/null
+++ b/doc/sphinx/man/lfun/UnwearArmour
@@ -0,0 +1,65 @@
+
+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
new file mode 100644
index 0000000..fe0372b
--- /dev/null
+++ b/doc/sphinx/man/lfun/UnwearClothing
@@ -0,0 +1,65 @@
+
+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
new file mode 100644
index 0000000..0301182
--- /dev/null
+++ b/doc/sphinx/man/lfun/UnwieldFunc
@@ -0,0 +1,74 @@
+
+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
new file mode 100644
index 0000000..cdebaa7
--- /dev/null
+++ b/doc/sphinx/man/lfun/UpdateAttributes
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..8ae9198
--- /dev/null
+++ b/doc/sphinx/man/lfun/UpdateResistanceStrengths
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..d11723c
--- /dev/null
+++ b/doc/sphinx/man/lfun/UseHands
@@ -0,0 +1,61 @@
+
+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
new file mode 100644
index 0000000..4f3398d
--- /dev/null
+++ b/doc/sphinx/man/lfun/UseSkill
@@ -0,0 +1,74 @@
+
+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
new file mode 100644
index 0000000..b5cfbf7
--- /dev/null
+++ b/doc/sphinx/man/lfun/UseSpell
@@ -0,0 +1,105 @@
+
+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
new file mode 100644
index 0000000..ddfceef
--- /dev/null
+++ b/doc/sphinx/man/lfun/Validate
@@ -0,0 +1,74 @@
+
+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
new file mode 100644
index 0000000..6a46903
--- /dev/null
+++ b/doc/sphinx/man/lfun/Wear
@@ -0,0 +1,64 @@
+
+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
new file mode 100644
index 0000000..a6961b2
--- /dev/null
+++ b/doc/sphinx/man/lfun/WearArmour
@@ -0,0 +1,64 @@
+
+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
new file mode 100644
index 0000000..51cc015
--- /dev/null
+++ b/doc/sphinx/man/lfun/WearClothing
@@ -0,0 +1,64 @@
+
+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
new file mode 100644
index 0000000..d1d0121
--- /dev/null
+++ b/doc/sphinx/man/lfun/WearFunc
@@ -0,0 +1,105 @@
+
+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
new file mode 100644
index 0000000..7c607e4
--- /dev/null
+++ b/doc/sphinx/man/lfun/WieldFunc
@@ -0,0 +1,102 @@
+
+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
new file mode 100644
index 0000000..1bff547
--- /dev/null
+++ b/doc/sphinx/man/lfun/WithDraw
@@ -0,0 +1,69 @@
+
+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
new file mode 100644
index 0000000..3ba4793
--- /dev/null
+++ b/doc/sphinx/man/lfun/__INIT
@@ -0,0 +1,25 @@
+
+__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
new file mode 100644
index 0000000..db3663f
--- /dev/null
+++ b/doc/sphinx/man/lfun/_query_current_money
@@ -0,0 +1,53 @@
+
+_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
new file mode 100644
index 0000000..caf3653
--- /dev/null
+++ b/doc/sphinx/man/lfun/_unparsed_args
@@ -0,0 +1,49 @@
+
+_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
new file mode 100644
index 0000000..7a99a99
--- /dev/null
+++ b/doc/sphinx/man/lfun/access_rights
@@ -0,0 +1,98 @@
+
+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
new file mode 100644
index 0000000..181751c
--- /dev/null
+++ b/doc/sphinx/man/lfun/buffer_hp
@@ -0,0 +1,104 @@
+
+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
new file mode 100644
index 0000000..09cad72
--- /dev/null
+++ b/doc/sphinx/man/lfun/buffer_sp
@@ -0,0 +1,63 @@
+
+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
new file mode 100644
index 0000000..0f0b965
--- /dev/null
+++ b/doc/sphinx/man/lfun/buy_obj
@@ -0,0 +1,65 @@
+
+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
new file mode 100644
index 0000000..42d1950
--- /dev/null
+++ b/doc/sphinx/man/lfun/catch_msg
@@ -0,0 +1,26 @@
+
+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
new file mode 100644
index 0000000..ff4e030
--- /dev/null
+++ b/doc/sphinx/man/lfun/catch_tell
@@ -0,0 +1,36 @@
+
+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
new file mode 100644
index 0000000..aa96667
--- /dev/null
+++ b/doc/sphinx/man/lfun/check_and_update_timed_key
@@ -0,0 +1,114 @@
+
+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
new file mode 100644
index 0000000..e173e8f
--- /dev/null
+++ b/doc/sphinx/man/lfun/check_restrictions
@@ -0,0 +1,202 @@
+
+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
new file mode 100644
index 0000000..58c70ab
--- /dev/null
+++ b/doc/sphinx/man/lfun/check_timed_key
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..7c124fb
--- /dev/null
+++ b/doc/sphinx/man/lfun/clean_up
@@ -0,0 +1,67 @@
+
+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
new file mode 100644
index 0000000..9cbc9b9
--- /dev/null
+++ b/doc/sphinx/man/lfun/cmd_shoot
@@ -0,0 +1,54 @@
+
+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
new file mode 100644
index 0000000..77a3cc5
--- /dev/null
+++ b/doc/sphinx/man/lfun/command_me
@@ -0,0 +1,110 @@
+
+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
new file mode 100644
index 0000000..f07ece3
--- /dev/null
+++ b/doc/sphinx/man/lfun/consume
@@ -0,0 +1,115 @@
+
+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
new file mode 100644
index 0000000..03fc91a
--- /dev/null
+++ b/doc/sphinx/man/lfun/create
@@ -0,0 +1,104 @@
+
+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
new file mode 100644
index 0000000..09c3a14
--- /dev/null
+++ b/doc/sphinx/man/lfun/create_default_npc
@@ -0,0 +1,76 @@
+
+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
new file mode 100644
index 0000000..101531f
--- /dev/null
+++ b/doc/sphinx/man/lfun/create_super
@@ -0,0 +1,75 @@
+
+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
new file mode 100644
index 0000000..266907e
--- /dev/null
+++ b/doc/sphinx/man/lfun/defuel_drink
@@ -0,0 +1,87 @@
+
+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
new file mode 100644
index 0000000..380c2bc
--- /dev/null
+++ b/doc/sphinx/man/lfun/defuel_food
@@ -0,0 +1,113 @@
+
+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
new file mode 100644
index 0000000..eb0c160
--- /dev/null
+++ b/doc/sphinx/man/lfun/deregister_modifier
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..a76a1aa
--- /dev/null
+++ b/doc/sphinx/man/lfun/die
@@ -0,0 +1,67 @@
+
+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
new file mode 100644
index 0000000..b6128ce
--- /dev/null
+++ b/doc/sphinx/man/lfun/doUnwearMessage
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..f2245b6
--- /dev/null
+++ b/doc/sphinx/man/lfun/doUnwieldMessage
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..6770180
--- /dev/null
+++ b/doc/sphinx/man/lfun/doWearMessage
@@ -0,0 +1,44 @@
+
+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
new file mode 100644
index 0000000..a3b737f
--- /dev/null
+++ b/doc/sphinx/man/lfun/doWieldMessage
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..91c6bc8
--- /dev/null
+++ b/doc/sphinx/man/lfun/do_damage
@@ -0,0 +1,70 @@
+
+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
new file mode 100644
index 0000000..6c848b8
--- /dev/null
+++ b/doc/sphinx/man/lfun/do_frage
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..dd91478
--- /dev/null
+++ b/doc/sphinx/man/lfun/do_unwear
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..abf7051
--- /dev/null
+++ b/doc/sphinx/man/lfun/do_wear
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..01d0a77
--- /dev/null
+++ b/doc/sphinx/man/lfun/drink_alcohol
@@ -0,0 +1,112 @@
+
+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
new file mode 100644
index 0000000..0f030f6
--- /dev/null
+++ b/doc/sphinx/man/lfun/drink_soft
@@ -0,0 +1,111 @@
+
+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
new file mode 100644
index 0000000..cdd372b
--- /dev/null
+++ b/doc/sphinx/man/lfun/drop
@@ -0,0 +1,70 @@
+
+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
new file mode 100644
index 0000000..3e1057f
--- /dev/null
+++ b/doc/sphinx/man/lfun/drop_obj
@@ -0,0 +1,44 @@
+
+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
new file mode 100644
index 0000000..93cbee5
--- /dev/null
+++ b/doc/sphinx/man/lfun/drop_objects
@@ -0,0 +1,73 @@
+
+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
new file mode 100644
index 0000000..32327e2
--- /dev/null
+++ b/doc/sphinx/man/lfun/eat_food
@@ -0,0 +1,114 @@
+
+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
new file mode 100644
index 0000000..39ec45a
--- /dev/null
+++ b/doc/sphinx/man/lfun/execute_anything
@@ -0,0 +1,64 @@
+
+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
new file mode 100644
index 0000000..f2d0b00
--- /dev/null
+++ b/doc/sphinx/man/lfun/exit
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..994ac6f
--- /dev/null
+++ b/doc/sphinx/man/lfun/find_obs
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..3500be1
--- /dev/null
+++ b/doc/sphinx/man/lfun/get_killing_player
@@ -0,0 +1,61 @@
+
+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
new file mode 100644
index 0000000..6be310b
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/AddSkill
@@ -0,0 +1,57 @@
+
+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
new file mode 100644
index 0000000..027b4d6
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/AddSpell
@@ -0,0 +1,74 @@
+
+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
new file mode 100644
index 0000000..ca4ec1b
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/GuildRating
@@ -0,0 +1,47 @@
+
+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
new file mode 100644
index 0000000..afea3e9
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/InitialSkillAbility
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..07a4dc9
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/LearnSkill
@@ -0,0 +1,59 @@
+
+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
new file mode 100644
index 0000000..385da3e
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/LearnSpell
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..ee3e68a
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/QuerySkill
@@ -0,0 +1,54 @@
+
+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
new file mode 100644
index 0000000..32eff3a
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/QuerySpell
@@ -0,0 +1,75 @@
+
+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
new file mode 100644
index 0000000..200650b
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/SkillListe
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..4f3724c
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/UseSpell
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..cde77e2
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/austreten
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..abed024
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/bei_oder_aus_treten
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..6e5a957
--- /dev/null
+++ b/doc/sphinx/man/lfun/gilde/beitreten
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..866c1e3
--- /dev/null
+++ b/doc/sphinx/man/lfun/give
@@ -0,0 +1,65 @@
+
+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
new file mode 100644
index 0000000..ef316cb
--- /dev/null
+++ b/doc/sphinx/man/lfun/give_notify
@@ -0,0 +1,87 @@
+
+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
new file mode 100644
index 0000000..753fd09
--- /dev/null
+++ b/doc/sphinx/man/lfun/give_obj
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..53697a2
--- /dev/null
+++ b/doc/sphinx/man/lfun/heal_self
@@ -0,0 +1,68 @@
+
+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
new file mode 100644
index 0000000..475a781
--- /dev/null
+++ b/doc/sphinx/man/lfun/heart_beat
@@ -0,0 +1,57 @@
+
+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
new file mode 100644
index 0000000..4921395
--- /dev/null
+++ b/doc/sphinx/man/lfun/id
@@ -0,0 +1,99 @@
+
+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
new file mode 100644
index 0000000..481eec2
--- /dev/null
+++ b/doc/sphinx/man/lfun/init
@@ -0,0 +1,91 @@
+
+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
new file mode 100644
index 0000000..513632a
--- /dev/null
+++ b/doc/sphinx/man/lfun/insert_sensitive_inv
@@ -0,0 +1,36 @@
+
+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
new file mode 100644
index 0000000..edb78f8
--- /dev/null
+++ b/doc/sphinx/man/lfun/insert_sensitive_inv_trigger
@@ -0,0 +1,36 @@
+
+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
new file mode 100644
index 0000000..931e132
--- /dev/null
+++ b/doc/sphinx/man/lfun/int_long
@@ -0,0 +1,91 @@
+
+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
new file mode 100644
index 0000000..aabd547
--- /dev/null
+++ b/doc/sphinx/man/lfun/int_short
@@ -0,0 +1,85 @@
+
+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
new file mode 100644
index 0000000..1018e71
--- /dev/null
+++ b/doc/sphinx/man/lfun/is_class_member
@@ -0,0 +1,174 @@
+
+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
new file mode 100644
index 0000000..6e35081
--- /dev/null
+++ b/doc/sphinx/man/lfun/lfun
@@ -0,0 +1,25 @@
+
+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
new file mode 100644
index 0000000..5854980
--- /dev/null
+++ b/doc/sphinx/man/lfun/locate_objects
@@ -0,0 +1,79 @@
+
+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
new file mode 100644
index 0000000..4fb7117
--- /dev/null
+++ b/doc/sphinx/man/lfun/logon
@@ -0,0 +1,26 @@
+
+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
new file mode 100644
index 0000000..a186cf9
--- /dev/null
+++ b/doc/sphinx/man/lfun/long
@@ -0,0 +1,55 @@
+
+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
new file mode 100644
index 0000000..9d0f402
--- /dev/null
+++ b/doc/sphinx/man/lfun/make_immortal
@@ -0,0 +1,44 @@
+
+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
new file mode 100644
index 0000000..379b47c
--- /dev/null
+++ b/doc/sphinx/man/lfun/make_invlist
@@ -0,0 +1,59 @@
+
+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
new file mode 100644
index 0000000..249e27c
--- /dev/null
+++ b/doc/sphinx/man/lfun/master/AddWizardForUID
@@ -0,0 +1,74 @@
+
+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
new file mode 100644
index 0000000..8f58509
--- /dev/null
+++ b/doc/sphinx/man/lfun/master/QueryUIDAlias
@@ -0,0 +1,65 @@
+
+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
new file mode 100644
index 0000000..e0d5816
--- /dev/null
+++ b/doc/sphinx/man/lfun/master/QueryUIDsForWizard
@@ -0,0 +1,64 @@
+
+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
new file mode 100644
index 0000000..6ddbdc3
--- /dev/null
+++ b/doc/sphinx/man/lfun/master/QueryWizardsForUID
@@ -0,0 +1,71 @@
+
+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
new file mode 100644
index 0000000..1fdeba5
--- /dev/null
+++ b/doc/sphinx/man/lfun/master/RemoveWizardFromUID
@@ -0,0 +1,62 @@
+
+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
new file mode 100644
index 0000000..48f368f
--- /dev/null
+++ b/doc/sphinx/man/lfun/match_ids
@@ -0,0 +1,69 @@
+
+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
new file mode 100644
index 0000000..bd9d924
--- /dev/null
+++ b/doc/sphinx/man/lfun/move
@@ -0,0 +1,242 @@
+
+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
new file mode 100644
index 0000000..8a5b536
--- /dev/null
+++ b/doc/sphinx/man/lfun/moved_objects
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..640acae
--- /dev/null
+++ b/doc/sphinx/man/lfun/moved_where
@@ -0,0 +1,50 @@
+
+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
new file mode 100644
index 0000000..aa7279c
--- /dev/null
+++ b/doc/sphinx/man/lfun/muster
@@ -0,0 +1,33 @@
+
+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
new file mode 100644
index 0000000..3509366
--- /dev/null
+++ b/doc/sphinx/man/lfun/name
@@ -0,0 +1,81 @@
+
+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
new file mode 100644
index 0000000..34c4024
--- /dev/null
+++ b/doc/sphinx/man/lfun/notify_player_change
@@ -0,0 +1,82 @@
+
+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
new file mode 100644
index 0000000..5a2adce
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/AddHpHook
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..9a372ba
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/AddInsertHook
@@ -0,0 +1,85 @@
+
+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
new file mode 100644
index 0000000..b0b81ab
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/ModifySkillAttributeOld
@@ -0,0 +1,118 @@
+
+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
new file mode 100644
index 0000000..220942b
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/NotifyGiveQuest
@@ -0,0 +1,62 @@
+
+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
new file mode 100644
index 0000000..3c96222
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/NotifyHpChange
@@ -0,0 +1,71 @@
+
+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
new file mode 100644
index 0000000..2613f53
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/QueryEnemy
@@ -0,0 +1,51 @@
+
+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
new file mode 100644
index 0000000..317104c
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/QueryInsertHooks
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..77404ad
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/QueryOptQP
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..54c93ec
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/RemoveHpHook
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..6c77edf
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/RemoveInsertHook
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..3d5d54d
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/TestAttributeLock
@@ -0,0 +1,47 @@
+
+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
new file mode 100644
index 0000000..d8e9703
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/extra_look
@@ -0,0 +1,32 @@
+
+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
new file mode 100644
index 0000000..25ce252
--- /dev/null
+++ b/doc/sphinx/man/lfun/obsolete/paramove
@@ -0,0 +1,66 @@
+
+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
new file mode 100644
index 0000000..5063ee6
--- /dev/null
+++ b/doc/sphinx/man/lfun/pick
@@ -0,0 +1,73 @@
+
+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
new file mode 100644
index 0000000..6557cee
--- /dev/null
+++ b/doc/sphinx/man/lfun/pick_obj
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..ac70415
--- /dev/null
+++ b/doc/sphinx/man/lfun/pick_objects
@@ -0,0 +1,61 @@
+
+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
new file mode 100644
index 0000000..77f31fa
--- /dev/null
+++ b/doc/sphinx/man/lfun/present_objects
@@ -0,0 +1,50 @@
+
+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
new file mode 100644
index 0000000..9b1d5eb
--- /dev/null
+++ b/doc/sphinx/man/lfun/put
@@ -0,0 +1,65 @@
+
+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
new file mode 100644
index 0000000..ff4dd91
--- /dev/null
+++ b/doc/sphinx/man/lfun/put_obj
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..2c8d2f3
--- /dev/null
+++ b/doc/sphinx/man/lfun/query_prevent_shadow
@@ -0,0 +1,54 @@
+
+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
new file mode 100644
index 0000000..1ebc69f
--- /dev/null
+++ b/doc/sphinx/man/lfun/query_real_name
@@ -0,0 +1,26 @@
+
+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
new file mode 100644
index 0000000..bd644f5
--- /dev/null
+++ b/doc/sphinx/man/lfun/query_weight_contents
@@ -0,0 +1,36 @@
+
+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
new file mode 100644
index 0000000..7a1dcf0
--- /dev/null
+++ b/doc/sphinx/man/lfun/reduce_hit_points
@@ -0,0 +1,69 @@
+
+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
new file mode 100644
index 0000000..cddb7da
--- /dev/null
+++ b/doc/sphinx/man/lfun/reduce_spell_points
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..afe086c
--- /dev/null
+++ b/doc/sphinx/man/lfun/register_modifier
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..914c1e1
--- /dev/null
+++ b/doc/sphinx/man/lfun/remove
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..9e60d55
--- /dev/null
+++ b/doc/sphinx/man/lfun/remove_multiple
@@ -0,0 +1,86 @@
+
+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
new file mode 100644
index 0000000..5959b3f
--- /dev/null
+++ b/doc/sphinx/man/lfun/reset
@@ -0,0 +1,106 @@
+
+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
new file mode 100644
index 0000000..b4917cf
--- /dev/null
+++ b/doc/sphinx/man/lfun/restore_hit_points
@@ -0,0 +1,57 @@
+
+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
new file mode 100644
index 0000000..2c8e42c
--- /dev/null
+++ b/doc/sphinx/man/lfun/restore_spell_points
@@ -0,0 +1,61 @@
+
+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
new file mode 100644
index 0000000..cbce90a
--- /dev/null
+++ b/doc/sphinx/man/lfun/save_me
@@ -0,0 +1,41 @@
+
+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
new file mode 100644
index 0000000..1c3fc8b
--- /dev/null
+++ b/doc/sphinx/man/lfun/second_life
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..580fd87
--- /dev/null
+++ b/doc/sphinx/man/lfun/sell_obj
@@ -0,0 +1,59 @@
+
+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
new file mode 100644
index 0000000..9b77a9e
--- /dev/null
+++ b/doc/sphinx/man/lfun/set_object_next_reset
@@ -0,0 +1,41 @@
+
+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
new file mode 100644
index 0000000..f66be19
--- /dev/null
+++ b/doc/sphinx/man/lfun/shoot_dam
@@ -0,0 +1,63 @@
+
+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
new file mode 100644
index 0000000..f7bb169
--- /dev/null
+++ b/doc/sphinx/man/lfun/short
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..0ce99ac
--- /dev/null
+++ b/doc/sphinx/man/lfun/show_notify
@@ -0,0 +1,73 @@
+
+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
new file mode 100644
index 0000000..65f0df8
--- /dev/null
+++ b/doc/sphinx/man/lfun/spellbook/AddSpell
@@ -0,0 +1,78 @@
+
+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
new file mode 100644
index 0000000..6338e6d
--- /dev/null
+++ b/doc/sphinx/man/lfun/spellbook/Erfolg
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..8de112e
--- /dev/null
+++ b/doc/sphinx/man/lfun/spellbook/Learn
@@ -0,0 +1,54 @@
+
+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
new file mode 100644
index 0000000..5ffe8de
--- /dev/null
+++ b/doc/sphinx/man/lfun/spellbook/Misserfolg
@@ -0,0 +1,78 @@
+
+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
new file mode 100644
index 0000000..963d30c
--- /dev/null
+++ b/doc/sphinx/man/lfun/spellbook/QuerySpell
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..564c948
--- /dev/null
+++ b/doc/sphinx/man/lfun/spellbook/SpellSuccess
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..d66684e
--- /dev/null
+++ b/doc/sphinx/man/lfun/spellbook/TryAttackSpell
@@ -0,0 +1,57 @@
+
+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
new file mode 100644
index 0000000..f290fc8
--- /dev/null
+++ b/doc/sphinx/man/lfun/trigger_sensitive_attack
@@ -0,0 +1,97 @@
+
+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
new file mode 100644
index 0000000..27e26fb
--- /dev/null
+++ b/doc/sphinx/man/lfun/trigger_sensitive_inv
@@ -0,0 +1,61 @@
+
+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
new file mode 100644
index 0000000..d1aa842
--- /dev/null
+++ b/doc/sphinx/man/lfun/wield_me
@@ -0,0 +1,17 @@
+
+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
new file mode 100644
index 0000000..b56c734
--- /dev/null
+++ b/doc/sphinx/man/lfuns-gilde
@@ -0,0 +1,3 @@
+
+Verzeichnis der lfuns speziell in/für Gilden
+********************************************
diff --git a/doc/sphinx/man/lfuns-master b/doc/sphinx/man/lfuns-master
new file mode 100644
index 0000000..7ca731d
--- /dev/null
+++ b/doc/sphinx/man/lfuns-master
@@ -0,0 +1,13 @@
+
+Verzeichnis der lfuns in master()
+*********************************
+
+* AddWizardForUID()
+
+* QueryUIDAlias()
+
+* QueryUIDsForWizard()
+
+* QueryWizardsForUID()
+
+* RemoveWizardFromUID()
diff --git a/doc/sphinx/man/lfuns-obsolet b/doc/sphinx/man/lfuns-obsolet
new file mode 100644
index 0000000..ac47c41
--- /dev/null
+++ b/doc/sphinx/man/lfuns-obsolet
@@ -0,0 +1,29 @@
+
+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
new file mode 100644
index 0000000..df0782d
--- /dev/null
+++ b/doc/sphinx/man/props-gilden
@@ -0,0 +1,17 @@
+
+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
new file mode 100644
index 0000000..f63a1cf
--- /dev/null
+++ b/doc/sphinx/man/props-liste
@@ -0,0 +1,937 @@
+
+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
new file mode 100644
index 0000000..a7e8edd
--- /dev/null
+++ b/doc/sphinx/man/props-obsolet
@@ -0,0 +1,29 @@
+
+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
new file mode 100644
index 0000000..b63a77e
--- /dev/null
+++ b/doc/sphinx/man/props.index
@@ -0,0 +1,159 @@
+
+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
new file mode 100644
index 0000000..b852bdf
--- /dev/null
+++ b/doc/sphinx/man/props/P_ABILITIES
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..e9eda47
--- /dev/null
+++ b/doc/sphinx/man/props/P_AC
@@ -0,0 +1,44 @@
+
+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
new file mode 100644
index 0000000..214dc06
--- /dev/null
+++ b/doc/sphinx/man/props/P_ACCEPT_PEACE
@@ -0,0 +1,37 @@
+
+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
new file mode 100644
index 0000000..c62e357
--- /dev/null
+++ b/doc/sphinx/man/props/P_ACHATS
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..fc28ac9
--- /dev/null
+++ b/doc/sphinx/man/props/P_ACHAT_CHANCE
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..0c9acd1
--- /dev/null
+++ b/doc/sphinx/man/props/P_ACTUAL_NOTIFY_FAIL
@@ -0,0 +1,51 @@
+
+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
new file mode 100644
index 0000000..1c8ccb6
--- /dev/null
+++ b/doc/sphinx/man/props/P_ADJECTIVES
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..781510c
--- /dev/null
+++ b/doc/sphinx/man/props/P_AERIAL_HELPERS
@@ -0,0 +1,63 @@
+
+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
new file mode 100644
index 0000000..e35473c
--- /dev/null
+++ b/doc/sphinx/man/props/P_AGE
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..5184687
--- /dev/null
+++ b/doc/sphinx/man/props/P_AGGRESSIVE
@@ -0,0 +1,55 @@
+
+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
new file mode 100644
index 0000000..d827a94
--- /dev/null
+++ b/doc/sphinx/man/props/P_ALCOHOL
@@ -0,0 +1,36 @@
+
+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
new file mode 100644
index 0000000..6ea0513
--- /dev/null
+++ b/doc/sphinx/man/props/P_ALCOHOL_DELAY
@@ -0,0 +1,23 @@
+
+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
new file mode 100644
index 0000000..5df4b65
--- /dev/null
+++ b/doc/sphinx/man/props/P_ALC_FULL_MSG
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..d4ca76c
--- /dev/null
+++ b/doc/sphinx/man/props/P_ALIGN
@@ -0,0 +1,29 @@
+
+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
new file mode 100644
index 0000000..5d849b7
--- /dev/null
+++ b/doc/sphinx/man/props/P_ALLOWED_SHADOW
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..cbe7f56
--- /dev/null
+++ b/doc/sphinx/man/props/P_AMMUNITION
@@ -0,0 +1,62 @@
+
+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
new file mode 100644
index 0000000..5c0e51a
--- /dev/null
+++ b/doc/sphinx/man/props/P_AMOUNT
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..8429a41
--- /dev/null
+++ b/doc/sphinx/man/props/P_AQUATIC_HELPERS
@@ -0,0 +1,64 @@
+
+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
new file mode 100644
index 0000000..e0d6a0c
--- /dev/null
+++ b/doc/sphinx/man/props/P_ARMOURS
@@ -0,0 +1,41 @@
+
+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
new file mode 100644
index 0000000..19e6812
--- /dev/null
+++ b/doc/sphinx/man/props/P_ARMOUR_TYPE
@@ -0,0 +1,63 @@
+
+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
new file mode 100644
index 0000000..cdafdaa
--- /dev/null
+++ b/doc/sphinx/man/props/P_ARRIVEMSG
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..2bf2c54
--- /dev/null
+++ b/doc/sphinx/man/props/P_ARTICLE
@@ -0,0 +1,28 @@
+
+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
new file mode 100644
index 0000000..dfc8ba6
--- /dev/null
+++ b/doc/sphinx/man/props/P_ATTACK_BUSY
@@ -0,0 +1,67 @@
+
+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
new file mode 100644
index 0000000..ed5dd1c
--- /dev/null
+++ b/doc/sphinx/man/props/P_ATTRIBUTES
@@ -0,0 +1,79 @@
+
+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
new file mode 100644
index 0000000..ab9f24d
--- /dev/null
+++ b/doc/sphinx/man/props/P_ATTRIBUTES_MODIFIER
@@ -0,0 +1,78 @@
+
+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
new file mode 100644
index 0000000..dfcbb8c
--- /dev/null
+++ b/doc/sphinx/man/props/P_ATTRIBUTES_OFFSETS
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..953b519
--- /dev/null
+++ b/doc/sphinx/man/props/P_AUTH_INFO
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..5e623bb
--- /dev/null
+++ b/doc/sphinx/man/props/P_AUTOLOAD
@@ -0,0 +1,31 @@
+
+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
new file mode 100644
index 0000000..3184fff
--- /dev/null
+++ b/doc/sphinx/man/props/P_AUTOLOADOBJ
@@ -0,0 +1,141 @@
+
+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
new file mode 100644
index 0000000..0a2437c
--- /dev/null
+++ b/doc/sphinx/man/props/P_AVATAR_URI
@@ -0,0 +1,44 @@
+
+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
new file mode 100644
index 0000000..155528f
--- /dev/null
+++ b/doc/sphinx/man/props/P_AVERAGE_SIZE
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..d71c53b
--- /dev/null
+++ b/doc/sphinx/man/props/P_AVERAGE_WEIGHT
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..5678440
--- /dev/null
+++ b/doc/sphinx/man/props/P_AWAY
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..7015a9c
--- /dev/null
+++ b/doc/sphinx/man/props/P_BAD_MSG
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..da86624
--- /dev/null
+++ b/doc/sphinx/man/props/P_BLIND
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..5871adb
--- /dev/null
+++ b/doc/sphinx/man/props/P_BODY
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..f6d3769
--- /dev/null
+++ b/doc/sphinx/man/props/P_BRIEF
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..699f91c
--- /dev/null
+++ b/doc/sphinx/man/props/P_BUFFER
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..0d15a94
--- /dev/null
+++ b/doc/sphinx/man/props/P_BUY_ONLY_PLANTS
@@ -0,0 +1,31 @@
+
+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
new file mode 100644
index 0000000..306241c
--- /dev/null
+++ b/doc/sphinx/man/props/P_CALLED_FROM_IP
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..06afe76
--- /dev/null
+++ b/doc/sphinx/man/props/P_CAN_FLAGS
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..0069948
--- /dev/null
+++ b/doc/sphinx/man/props/P_CAP_NAME
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..8792664
--- /dev/null
+++ b/doc/sphinx/man/props/P_CARRIED_VALUE
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..51e1a5e
--- /dev/null
+++ b/doc/sphinx/man/props/P_CHATS
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..bd032bf
--- /dev/null
+++ b/doc/sphinx/man/props/P_CHAT_CHANCE
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..80017cc
--- /dev/null
+++ b/doc/sphinx/man/props/P_CLASS
@@ -0,0 +1,33 @@
+
+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
new file mode 100644
index 0000000..6f85b56
--- /dev/null
+++ b/doc/sphinx/man/props/P_CLOCKMSG
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..75e9d02
--- /dev/null
+++ b/doc/sphinx/man/props/P_CLONER
@@ -0,0 +1,28 @@
+
+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
new file mode 100644
index 0000000..d16f42e
--- /dev/null
+++ b/doc/sphinx/man/props/P_CLONE_MSG
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..fb7c3e5
--- /dev/null
+++ b/doc/sphinx/man/props/P_CLONE_TIME
@@ -0,0 +1,30 @@
+
+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
new file mode 100644
index 0000000..3458058
--- /dev/null
+++ b/doc/sphinx/man/props/P_CLOTHING
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..e38f085
--- /dev/null
+++ b/doc/sphinx/man/props/P_CMSG
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..5bcc584
--- /dev/null
+++ b/doc/sphinx/man/props/P_CNT_STATUS
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..e82336a
--- /dev/null
+++ b/doc/sphinx/man/props/P_COMBATCMDS
@@ -0,0 +1,44 @@
+
+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
new file mode 100644
index 0000000..5812b35
--- /dev/null
+++ b/doc/sphinx/man/props/P_COMMANDS
@@ -0,0 +1,76 @@
+
+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
new file mode 100644
index 0000000..e67d01f
--- /dev/null
+++ b/doc/sphinx/man/props/P_COMPILER_PATH
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..0300037
--- /dev/null
+++ b/doc/sphinx/man/props/P_CONSUME_MSG
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..e779f75
--- /dev/null
+++ b/doc/sphinx/man/props/P_CONTAINER
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..fc9f20e
--- /dev/null
+++ b/doc/sphinx/man/props/P_CONTENTS
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..762f03c
--- /dev/null
+++ b/doc/sphinx/man/props/P_CORPSE
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..b1dc2a4
--- /dev/null
+++ b/doc/sphinx/man/props/P_CURRENTDIR
@@ -0,0 +1,28 @@
+
+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
new file mode 100644
index 0000000..c3a9061
--- /dev/null
+++ b/doc/sphinx/man/props/P_CURSED
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..91d5324
--- /dev/null
+++ b/doc/sphinx/man/props/P_DAMAGED
@@ -0,0 +1,41 @@
+
+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
new file mode 100644
index 0000000..e9c71a8
--- /dev/null
+++ b/doc/sphinx/man/props/P_DAMAGE_MSG
@@ -0,0 +1,58 @@
+
+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
new file mode 100644
index 0000000..151f555
--- /dev/null
+++ b/doc/sphinx/man/props/P_DAM_DESC
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..e5088d2
--- /dev/null
+++ b/doc/sphinx/man/props/P_DAM_TYPE
@@ -0,0 +1,35 @@
+
+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
new file mode 100644
index 0000000..03f0c07
--- /dev/null
+++ b/doc/sphinx/man/props/P_DEADS
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..570ac06
--- /dev/null
+++ b/doc/sphinx/man/props/P_DEAF
@@ -0,0 +1,23 @@
+
+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
new file mode 100644
index 0000000..d5de007
--- /dev/null
+++ b/doc/sphinx/man/props/P_DEATH_MSG
@@ -0,0 +1,79 @@
+
+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
new file mode 100644
index 0000000..cae8532
--- /dev/null
+++ b/doc/sphinx/man/props/P_DEATH_SPONSORED_BY
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..55abd50
--- /dev/null
+++ b/doc/sphinx/man/props/P_DEFAULT_GUILD
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..351c96c
--- /dev/null
+++ b/doc/sphinx/man/props/P_DEFAULT_NOTIFY_FAIL
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..a54134a
--- /dev/null
+++ b/doc/sphinx/man/props/P_DEFENDERS
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..a9939e1
--- /dev/null
+++ b/doc/sphinx/man/props/P_DEFEND_FUNC
@@ -0,0 +1,50 @@
+
+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
new file mode 100644
index 0000000..79dcfa5
--- /dev/null
+++ b/doc/sphinx/man/props/P_DEFUEL_AMOUNT_DRINK
@@ -0,0 +1,36 @@
+
+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
new file mode 100644
index 0000000..f61a23e
--- /dev/null
+++ b/doc/sphinx/man/props/P_DEFUEL_AMOUNT_FOOD
@@ -0,0 +1,36 @@
+
+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
new file mode 100644
index 0000000..d3a2c3c
--- /dev/null
+++ b/doc/sphinx/man/props/P_DEFUEL_LIMIT_DRINK
@@ -0,0 +1,37 @@
+
+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
new file mode 100644
index 0000000..bb012a3
--- /dev/null
+++ b/doc/sphinx/man/props/P_DEFUEL_LIMIT_FOOD
@@ -0,0 +1,37 @@
+
+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
new file mode 100644
index 0000000..3ff3b74
--- /dev/null
+++ b/doc/sphinx/man/props/P_DEFUEL_TIME_DRINK
@@ -0,0 +1,37 @@
+
+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
new file mode 100644
index 0000000..fcd80d0
--- /dev/null
+++ b/doc/sphinx/man/props/P_DEFUEL_TIME_FOOD
@@ -0,0 +1,37 @@
+
+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
new file mode 100644
index 0000000..917e01c
--- /dev/null
+++ b/doc/sphinx/man/props/P_DEPARTMSG
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..4d32999
--- /dev/null
+++ b/doc/sphinx/man/props/P_DESCRIPTION
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..94f00e5
--- /dev/null
+++ b/doc/sphinx/man/props/P_DESTROY_BAD
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..334c374
--- /dev/null
+++ b/doc/sphinx/man/props/P_DESTRUCT_MSG
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..e14c15c
--- /dev/null
+++ b/doc/sphinx/man/props/P_DETAILS
@@ -0,0 +1,44 @@
+
+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
new file mode 100644
index 0000000..0bd5d17
--- /dev/null
+++ b/doc/sphinx/man/props/P_DIE_MSG
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..37544ae
--- /dev/null
+++ b/doc/sphinx/man/props/P_DISABLE_ATTACK
@@ -0,0 +1,64 @@
+
+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
new file mode 100644
index 0000000..e66910a
--- /dev/null
+++ b/doc/sphinx/man/props/P_DISABLE_COMMANDS
@@ -0,0 +1,100 @@
+
+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
new file mode 100644
index 0000000..51140ae
--- /dev/null
+++ b/doc/sphinx/man/props/P_DISTRIBUTION
@@ -0,0 +1,31 @@
+
+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
new file mode 100644
index 0000000..40af065
--- /dev/null
+++ b/doc/sphinx/man/props/P_DMSG
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..aad5288
--- /dev/null
+++ b/doc/sphinx/man/props/P_DOMAIN
@@ -0,0 +1,50 @@
+
+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
new file mode 100644
index 0000000..dc393da
--- /dev/null
+++ b/doc/sphinx/man/props/P_DOOR_INFOS
@@ -0,0 +1,58 @@
+
+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
new file mode 100644
index 0000000..6aa9384
--- /dev/null
+++ b/doc/sphinx/man/props/P_DO_DESTRUCT
@@ -0,0 +1,36 @@
+
+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
new file mode 100644
index 0000000..028e987
--- /dev/null
+++ b/doc/sphinx/man/props/P_DRINK
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..1617b47
--- /dev/null
+++ b/doc/sphinx/man/props/P_DRINK_DELAY
@@ -0,0 +1,23 @@
+
+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
new file mode 100644
index 0000000..1e5c2ce
--- /dev/null
+++ b/doc/sphinx/man/props/P_DRINK_FULL_MSG
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..9ccb875
--- /dev/null
+++ b/doc/sphinx/man/props/P_DROP_MSG
@@ -0,0 +1,96 @@
+
+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
new file mode 100644
index 0000000..e5b4bbb
--- /dev/null
+++ b/doc/sphinx/man/props/P_EARMUFFS
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..132469d
--- /dev/null
+++ b/doc/sphinx/man/props/P_EATER_MSG
@@ -0,0 +1,44 @@
+
+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
new file mode 100644
index 0000000..5473d5d
--- /dev/null
+++ b/doc/sphinx/man/props/P_EFFECTIVE_AC
@@ -0,0 +1,107 @@
+
+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
new file mode 100644
index 0000000..aa16980
--- /dev/null
+++ b/doc/sphinx/man/props/P_EFFECTIVE_WC
@@ -0,0 +1,112 @@
+
+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
new file mode 100644
index 0000000..e91d622
--- /dev/null
+++ b/doc/sphinx/man/props/P_EMPTY_MSG
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..6f5c126
--- /dev/null
+++ b/doc/sphinx/man/props/P_EMPTY_PROPS
@@ -0,0 +1,54 @@
+
+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
new file mode 100644
index 0000000..0a64c74
--- /dev/null
+++ b/doc/sphinx/man/props/P_ENABLE_IN_ATTACK_OUT
@@ -0,0 +1,51 @@
+
+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
new file mode 100644
index 0000000..bad9c99
--- /dev/null
+++ b/doc/sphinx/man/props/P_ENEMY_DAMAGE
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..03b2bec
--- /dev/null
+++ b/doc/sphinx/man/props/P_ENEMY_DEATH_SEQUENCE
@@ -0,0 +1,61 @@
+
+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
new file mode 100644
index 0000000..fc6f72f
--- /dev/null
+++ b/doc/sphinx/man/props/P_ENTERCMDS
@@ -0,0 +1,57 @@
+
+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
new file mode 100644
index 0000000..5291065
--- /dev/null
+++ b/doc/sphinx/man/props/P_ENTERFAIL
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..9ba314d
--- /dev/null
+++ b/doc/sphinx/man/props/P_ENTERMSG
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..e969399
--- /dev/null
+++ b/doc/sphinx/man/props/P_ENV_MSG
@@ -0,0 +1,47 @@
+
+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
new file mode 100644
index 0000000..23c1d6c
--- /dev/null
+++ b/doc/sphinx/man/props/P_ENV_TOO_HEAVY_MSG
@@ -0,0 +1,50 @@
+
+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
new file mode 100644
index 0000000..ee0d07f
--- /dev/null
+++ b/doc/sphinx/man/props/P_EQUIP_TIME
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..ed83d4e
--- /dev/null
+++ b/doc/sphinx/man/props/P_EVAL_FACTORS
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..e571f51
--- /dev/null
+++ b/doc/sphinx/man/props/P_EVAL_OFFSETS
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..c31bac3
--- /dev/null
+++ b/doc/sphinx/man/props/P_EXITS
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..e4f050e
--- /dev/null
+++ b/doc/sphinx/man/props/P_EXTRA_LOOK
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..33f673e
--- /dev/null
+++ b/doc/sphinx/man/props/P_FAO
@@ -0,0 +1,33 @@
+
+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
new file mode 100644
index 0000000..5d80c90
--- /dev/null
+++ b/doc/sphinx/man/props/P_FAO_PORTALS
@@ -0,0 +1,36 @@
+
+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
new file mode 100644
index 0000000..0fa259f
--- /dev/null
+++ b/doc/sphinx/man/props/P_FISH
@@ -0,0 +1,92 @@
+
+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
new file mode 100644
index 0000000..3962aed
--- /dev/null
+++ b/doc/sphinx/man/props/P_FLAGS
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..6dd07b3
--- /dev/null
+++ b/doc/sphinx/man/props/P_FOLLOW_SILENT
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..3858431
--- /dev/null
+++ b/doc/sphinx/man/props/P_FOOD
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..f4eb2df
--- /dev/null
+++ b/doc/sphinx/man/props/P_FOOD_DELAY
@@ -0,0 +1,23 @@
+
+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
new file mode 100644
index 0000000..f5c1bce
--- /dev/null
+++ b/doc/sphinx/man/props/P_FOOD_FULL_MSG
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..709ef4e
--- /dev/null
+++ b/doc/sphinx/man/props/P_FORCE_MURDER_MSG
@@ -0,0 +1,57 @@
+
+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
new file mode 100644
index 0000000..c8311cc
--- /dev/null
+++ b/doc/sphinx/man/props/P_FREE_HANDS
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..b22203b
--- /dev/null
+++ b/doc/sphinx/man/props/P_FRIEND
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..71badbe
--- /dev/null
+++ b/doc/sphinx/man/props/P_FROG
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..79f8515
--- /dev/null
+++ b/doc/sphinx/man/props/P_FUEL
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..adcca1a
--- /dev/null
+++ b/doc/sphinx/man/props/P_FUNC_MSG
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..f770431
--- /dev/null
+++ b/doc/sphinx/man/props/P_FW_ALWAYS_READABLE
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..2884555
--- /dev/null
+++ b/doc/sphinx/man/props/P_FW_UNDERSTAND
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..c2a3f77
--- /dev/null
+++ b/doc/sphinx/man/props/P_GENDER
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..31c9f2d
--- /dev/null
+++ b/doc/sphinx/man/props/P_GHOST
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..e21dbad
--- /dev/null
+++ b/doc/sphinx/man/props/P_GIVE_MSG
@@ -0,0 +1,83 @@
+
+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
new file mode 100644
index 0000000..1e3533b
--- /dev/null
+++ b/doc/sphinx/man/props/P_GLOBAL_SKILLPROPS
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..7128df6
--- /dev/null
+++ b/doc/sphinx/man/props/P_GUARD
@@ -0,0 +1,70 @@
+
+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
new file mode 100644
index 0000000..c3c13cb
--- /dev/null
+++ b/doc/sphinx/man/props/P_GUILD
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..a53d6ce
--- /dev/null
+++ b/doc/sphinx/man/props/P_GUILD_DEACTIVATE_SKILLS
@@ -0,0 +1,50 @@
+
+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
new file mode 100644
index 0000000..4d6bbd0
--- /dev/null
+++ b/doc/sphinx/man/props/P_GUILD_DEFAULT_SPELLBOOK
@@ -0,0 +1,44 @@
+
+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
new file mode 100644
index 0000000..c06947d
--- /dev/null
+++ b/doc/sphinx/man/props/P_GUILD_FEMALE_TITLES
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..f38701c
--- /dev/null
+++ b/doc/sphinx/man/props/P_GUILD_LEVEL
@@ -0,0 +1,41 @@
+
+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
new file mode 100644
index 0000000..9b9b80d
--- /dev/null
+++ b/doc/sphinx/man/props/P_GUILD_LEVELS
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..41cb773
--- /dev/null
+++ b/doc/sphinx/man/props/P_GUILD_MALE_TITLES
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..ee1c361
--- /dev/null
+++ b/doc/sphinx/man/props/P_GUILD_PREPAREBLOCK
@@ -0,0 +1,60 @@
+
+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
new file mode 100644
index 0000000..af9c24e
--- /dev/null
+++ b/doc/sphinx/man/props/P_GUILD_RATING
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..c94ccf3
--- /dev/null
+++ b/doc/sphinx/man/props/P_GUILD_RESTRICTIONS
@@ -0,0 +1,59 @@
+
+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
new file mode 100644
index 0000000..232a5cf
--- /dev/null
+++ b/doc/sphinx/man/props/P_GUILD_SKILLS
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..d3a49b3
--- /dev/null
+++ b/doc/sphinx/man/props/P_GUILD_TITLE
@@ -0,0 +1,58 @@
+
+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
new file mode 100644
index 0000000..859b4eb
--- /dev/null
+++ b/doc/sphinx/man/props/P_HANDS
@@ -0,0 +1,78 @@
+
+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
new file mode 100644
index 0000000..f0d5165
--- /dev/null
+++ b/doc/sphinx/man/props/P_HANDS_USED_BY
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..f049847
--- /dev/null
+++ b/doc/sphinx/man/props/P_HARBOUR
@@ -0,0 +1,94 @@
+
+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
new file mode 100644
index 0000000..ffd5c8f
--- /dev/null
+++ b/doc/sphinx/man/props/P_HAUS_ERLAUBT
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..bdaf9f1
--- /dev/null
+++ b/doc/sphinx/man/props/P_HB
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..83d4991
--- /dev/null
+++ b/doc/sphinx/man/props/P_HEAL
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..af8bfef
--- /dev/null
+++ b/doc/sphinx/man/props/P_HELPER_NPC
@@ -0,0 +1,50 @@
+
+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
new file mode 100644
index 0000000..94990c4
--- /dev/null
+++ b/doc/sphinx/man/props/P_HELPER_OBJECTS
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..c9aa2e5
--- /dev/null
+++ b/doc/sphinx/man/props/P_HIDE_EXITS
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..ca35504
--- /dev/null
+++ b/doc/sphinx/man/props/P_HISTMIN
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..9bcc328
--- /dev/null
+++ b/doc/sphinx/man/props/P_HIT_FUNC
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..5cf6bec
--- /dev/null
+++ b/doc/sphinx/man/props/P_HOMEPAGE
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..b7ded4a
--- /dev/null
+++ b/doc/sphinx/man/props/P_HP
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..f15f748
--- /dev/null
+++ b/doc/sphinx/man/props/P_HP_DELAY
@@ -0,0 +1,23 @@
+
+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
new file mode 100644
index 0000000..7bb48bf
--- /dev/null
+++ b/doc/sphinx/man/props/P_HP_HOOKS
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..e712a49
--- /dev/null
+++ b/doc/sphinx/man/props/P_HUNTTIME
@@ -0,0 +1,59 @@
+
+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
new file mode 100644
index 0000000..dee9a74
--- /dev/null
+++ b/doc/sphinx/man/props/P_IDS
@@ -0,0 +1,41 @@
+
+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
new file mode 100644
index 0000000..3436a09
--- /dev/null
+++ b/doc/sphinx/man/props/P_IGNORE
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..4483d10
--- /dev/null
+++ b/doc/sphinx/man/props/P_INDOORS
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..f29c242
--- /dev/null
+++ b/doc/sphinx/man/props/P_INFO
@@ -0,0 +1,36 @@
+
+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
new file mode 100644
index 0000000..c6dd0ed
--- /dev/null
+++ b/doc/sphinx/man/props/P_INFORMME
@@ -0,0 +1,30 @@
+
+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
new file mode 100644
index 0000000..1eafd4d
--- /dev/null
+++ b/doc/sphinx/man/props/P_INPC_HOME
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..8f7cb68
--- /dev/null
+++ b/doc/sphinx/man/props/P_INPC_LAST_ENVIRONMENT
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..14f8730
--- /dev/null
+++ b/doc/sphinx/man/props/P_INPC_LAST_PLAYER_CONTACT
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..9554d27
--- /dev/null
+++ b/doc/sphinx/man/props/P_INPC_WALK_AREA
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..e59deea
--- /dev/null
+++ b/doc/sphinx/man/props/P_INPC_WALK_DELAYS
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..86c4835
--- /dev/null
+++ b/doc/sphinx/man/props/P_INPC_WALK_FLAGS
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..134bb50
--- /dev/null
+++ b/doc/sphinx/man/props/P_INPC_WALK_MODE
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..762408d
--- /dev/null
+++ b/doc/sphinx/man/props/P_INPC_WALK_ROUTE
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..8019998
--- /dev/null
+++ b/doc/sphinx/man/props/P_INTERMUD
@@ -0,0 +1,25 @@
+
+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
new file mode 100644
index 0000000..ffa78ad
--- /dev/null
+++ b/doc/sphinx/man/props/P_INTERNAL_EXTRA_LOOK
@@ -0,0 +1,57 @@
+
+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
new file mode 100644
index 0000000..dcf59b6
--- /dev/null
+++ b/doc/sphinx/man/props/P_INT_LIGHT
@@ -0,0 +1,36 @@
+
+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
new file mode 100644
index 0000000..741e511
--- /dev/null
+++ b/doc/sphinx/man/props/P_INT_LONG
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..618bbab
--- /dev/null
+++ b/doc/sphinx/man/props/P_INT_SHORT
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..4063546
--- /dev/null
+++ b/doc/sphinx/man/props/P_INVIS
@@ -0,0 +1,65 @@
+
+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
new file mode 100644
index 0000000..6003c80
--- /dev/null
+++ b/doc/sphinx/man/props/P_IP_NAME
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..2afcd60
--- /dev/null
+++ b/doc/sphinx/man/props/P_IS_ARTILLERY
@@ -0,0 +1,30 @@
+
+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
new file mode 100644
index 0000000..1fcafc5
--- /dev/null
+++ b/doc/sphinx/man/props/P_ITEMS
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..0a0eefc
--- /dev/null
+++ b/doc/sphinx/man/props/P_I_HATE_ALCOHOL
@@ -0,0 +1,41 @@
+
+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
new file mode 100644
index 0000000..63185c8
--- /dev/null
+++ b/doc/sphinx/man/props/P_KEEPER
@@ -0,0 +1,26 @@
+
+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
new file mode 100644
index 0000000..ce5feba
--- /dev/null
+++ b/doc/sphinx/man/props/P_KEEP_ON_SELL
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..01bb0d1
--- /dev/null
+++ b/doc/sphinx/man/props/P_KILLER
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..7ec3dac
--- /dev/null
+++ b/doc/sphinx/man/props/P_KILLS
@@ -0,0 +1,23 @@
+
+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
new file mode 100644
index 0000000..9437975
--- /dev/null
+++ b/doc/sphinx/man/props/P_KILL_MSG
@@ -0,0 +1,96 @@
+
+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
new file mode 100644
index 0000000..0504066
--- /dev/null
+++ b/doc/sphinx/man/props/P_KILL_NAME
@@ -0,0 +1,59 @@
+
+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
new file mode 100644
index 0000000..29e17d3
--- /dev/null
+++ b/doc/sphinx/man/props/P_KNOWN_POTIONROOMS
@@ -0,0 +1,35 @@
+
+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
new file mode 100644
index 0000000..2695f06
--- /dev/null
+++ b/doc/sphinx/man/props/P_LASTDIR
@@ -0,0 +1,28 @@
+
+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
new file mode 100644
index 0000000..941ec1e
--- /dev/null
+++ b/doc/sphinx/man/props/P_LAST_COMBAT_TIME
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..40bd6a0
--- /dev/null
+++ b/doc/sphinx/man/props/P_LAST_COMMAND_ENV
@@ -0,0 +1,30 @@
+
+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
new file mode 100644
index 0000000..f128774
--- /dev/null
+++ b/doc/sphinx/man/props/P_LAST_CONTENT_CHANGE
@@ -0,0 +1,32 @@
+
+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
new file mode 100644
index 0000000..66388b7
--- /dev/null
+++ b/doc/sphinx/man/props/P_LAST_DAMAGE
@@ -0,0 +1,37 @@
+
+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
new file mode 100644
index 0000000..7e6d0ea
--- /dev/null
+++ b/doc/sphinx/man/props/P_LAST_DAMTIME
@@ -0,0 +1,37 @@
+
+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
new file mode 100644
index 0000000..ecdf571
--- /dev/null
+++ b/doc/sphinx/man/props/P_LAST_DAMTYPES
@@ -0,0 +1,36 @@
+
+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
new file mode 100644
index 0000000..7249dad
--- /dev/null
+++ b/doc/sphinx/man/props/P_LAST_DEATH_PROPS
@@ -0,0 +1,32 @@
+
+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
new file mode 100644
index 0000000..669e7a1
--- /dev/null
+++ b/doc/sphinx/man/props/P_LAST_DEATH_TIME
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..4ad7360
--- /dev/null
+++ b/doc/sphinx/man/props/P_LAST_LOGIN
@@ -0,0 +1,35 @@
+
+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
new file mode 100644
index 0000000..e94e89e
--- /dev/null
+++ b/doc/sphinx/man/props/P_LAST_LOGOUT
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..f6c974a
--- /dev/null
+++ b/doc/sphinx/man/props/P_LAST_MOVE
@@ -0,0 +1,36 @@
+
+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
new file mode 100644
index 0000000..57519c9
--- /dev/null
+++ b/doc/sphinx/man/props/P_LAST_USE
@@ -0,0 +1,33 @@
+
+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
new file mode 100644
index 0000000..5531955
--- /dev/null
+++ b/doc/sphinx/man/props/P_LAST_WEAR_ACTION
@@ -0,0 +1,31 @@
+
+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
new file mode 100644
index 0000000..c31a8b4
--- /dev/null
+++ b/doc/sphinx/man/props/P_LAST_XP
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..5b0e03c
--- /dev/null
+++ b/doc/sphinx/man/props/P_LEAVECMDS
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..88e92ea
--- /dev/null
+++ b/doc/sphinx/man/props/P_LEAVEFAIL
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..a3a1baf
--- /dev/null
+++ b/doc/sphinx/man/props/P_LEAVEMSG
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..dbcea68
--- /dev/null
+++ b/doc/sphinx/man/props/P_LEP
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..a4b804c
--- /dev/null
+++ b/doc/sphinx/man/props/P_LEVEL
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..4c76f14
--- /dev/null
+++ b/doc/sphinx/man/props/P_LIFETIME
@@ -0,0 +1,51 @@
+
+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
new file mode 100644
index 0000000..d0b55d8
--- /dev/null
+++ b/doc/sphinx/man/props/P_LIGHT
@@ -0,0 +1,81 @@
+
+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
new file mode 100644
index 0000000..e8c52d1
--- /dev/null
+++ b/doc/sphinx/man/props/P_LIGHTDESC
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..31d7709
--- /dev/null
+++ b/doc/sphinx/man/props/P_LIGHTED
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..4443a98
--- /dev/null
+++ b/doc/sphinx/man/props/P_LIGHT_ABSORPTION
@@ -0,0 +1,31 @@
+
+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
new file mode 100644
index 0000000..c7741ee
--- /dev/null
+++ b/doc/sphinx/man/props/P_LIGHT_MODIFIER
@@ -0,0 +1,75 @@
+
+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
new file mode 100644
index 0000000..42d0d13
--- /dev/null
+++ b/doc/sphinx/man/props/P_LIGHT_TRANSPARENCY
@@ -0,0 +1,30 @@
+
+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
new file mode 100644
index 0000000..47abbf4
--- /dev/null
+++ b/doc/sphinx/man/props/P_LIGHT_TYPE
@@ -0,0 +1,106 @@
+
+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
new file mode 100644
index 0000000..55672bb
--- /dev/null
+++ b/doc/sphinx/man/props/P_LIQUID
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..02a3c2a
--- /dev/null
+++ b/doc/sphinx/man/props/P_LOCALCMDS
@@ -0,0 +1,25 @@
+
+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
new file mode 100644
index 0000000..cf2ed6c
--- /dev/null
+++ b/doc/sphinx/man/props/P_LOCATION
@@ -0,0 +1,32 @@
+
+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
new file mode 100644
index 0000000..0ed186d
--- /dev/null
+++ b/doc/sphinx/man/props/P_LOG_INFO
@@ -0,0 +1,55 @@
+
+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
new file mode 100644
index 0000000..bad7968
--- /dev/null
+++ b/doc/sphinx/man/props/P_LONG
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..cac74e0
--- /dev/null
+++ b/doc/sphinx/man/props/P_LONG_EMPTY
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..7de6081
--- /dev/null
+++ b/doc/sphinx/man/props/P_LONG_FULL
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..8994533
--- /dev/null
+++ b/doc/sphinx/man/props/P_MAGIC
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..8d270e3
--- /dev/null
+++ b/doc/sphinx/man/props/P_MAGIC_RESISTANCE_OFFSET
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..32556a7
--- /dev/null
+++ b/doc/sphinx/man/props/P_MAILADDR
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..ee9e620
--- /dev/null
+++ b/doc/sphinx/man/props/P_MAP_RESTRICTIONS
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..7cafa6f
--- /dev/null
+++ b/doc/sphinx/man/props/P_MARRIED
@@ -0,0 +1,28 @@
+
+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
new file mode 100644
index 0000000..4ea4032
--- /dev/null
+++ b/doc/sphinx/man/props/P_MATERIAL
@@ -0,0 +1,99 @@
+
+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
new file mode 100644
index 0000000..0694fef
--- /dev/null
+++ b/doc/sphinx/man/props/P_MATERIAL_KNOWLEDGE
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..541972f
--- /dev/null
+++ b/doc/sphinx/man/props/P_MAX_ALCOHOL
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..33fdeb8
--- /dev/null
+++ b/doc/sphinx/man/props/P_MAX_DRINK
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..fa7f661
--- /dev/null
+++ b/doc/sphinx/man/props/P_MAX_FOOD
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..4c65afa
--- /dev/null
+++ b/doc/sphinx/man/props/P_MAX_HANDS
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..fcb3cb0
--- /dev/null
+++ b/doc/sphinx/man/props/P_MAX_HP
@@ -0,0 +1,30 @@
+
+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
new file mode 100644
index 0000000..68c008f
--- /dev/null
+++ b/doc/sphinx/man/props/P_MAX_OBJECTS
@@ -0,0 +1,44 @@
+
+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
new file mode 100644
index 0000000..32e5f27
--- /dev/null
+++ b/doc/sphinx/man/props/P_MAX_PASSENGERS
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..0d39dc4
--- /dev/null
+++ b/doc/sphinx/man/props/P_MAX_POISON
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..7f7aa43
--- /dev/null
+++ b/doc/sphinx/man/props/P_MAX_SP
@@ -0,0 +1,30 @@
+
+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
new file mode 100644
index 0000000..abd0942
--- /dev/null
+++ b/doc/sphinx/man/props/P_MAX_WEIGHT
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..6ecf718
--- /dev/null
+++ b/doc/sphinx/man/props/P_MESSAGE_BEEP
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..be54d65
--- /dev/null
+++ b/doc/sphinx/man/props/P_MESSAGE_PREPEND
@@ -0,0 +1,37 @@
+
+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
new file mode 100644
index 0000000..3be8d4e
--- /dev/null
+++ b/doc/sphinx/man/props/P_MIN_STOCK
@@ -0,0 +1,55 @@
+
+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
new file mode 100644
index 0000000..98d37f3
--- /dev/null
+++ b/doc/sphinx/man/props/P_MMSGIN
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..6035ba8
--- /dev/null
+++ b/doc/sphinx/man/props/P_MMSGOUT
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..f5d90f8
--- /dev/null
+++ b/doc/sphinx/man/props/P_MSGIN
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..95a8545
--- /dev/null
+++ b/doc/sphinx/man/props/P_MSGOUT
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..b4465df
--- /dev/null
+++ b/doc/sphinx/man/props/P_MSG_PROB
@@ -0,0 +1,35 @@
+
+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
new file mode 100644
index 0000000..71801eb
--- /dev/null
+++ b/doc/sphinx/man/props/P_MUD_NEWBIE
@@ -0,0 +1,31 @@
+
+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
new file mode 100644
index 0000000..c565cfa
--- /dev/null
+++ b/doc/sphinx/man/props/P_MURDER_MSG
@@ -0,0 +1,83 @@
+
+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
new file mode 100644
index 0000000..d279484
--- /dev/null
+++ b/doc/sphinx/man/props/P_M_ATTR_MOD
@@ -0,0 +1,64 @@
+
+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
new file mode 100644
index 0000000..cdc3fd4
--- /dev/null
+++ b/doc/sphinx/man/props/P_M_HEALTH_MOD
@@ -0,0 +1,64 @@
+
+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
new file mode 100644
index 0000000..1fdc261
--- /dev/null
+++ b/doc/sphinx/man/props/P_NAME
@@ -0,0 +1,84 @@
+
+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
new file mode 100644
index 0000000..c4cc4a4
--- /dev/null
+++ b/doc/sphinx/man/props/P_NAME_ADJ
@@ -0,0 +1,72 @@
+
+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
new file mode 100644
index 0000000..2df4c78
--- /dev/null
+++ b/doc/sphinx/man/props/P_NEEDED_QP
@@ -0,0 +1,31 @@
+
+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
new file mode 100644
index 0000000..2e46f5d
--- /dev/null
+++ b/doc/sphinx/man/props/P_NETDEAD_ENV
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..fe96ac6
--- /dev/null
+++ b/doc/sphinx/man/props/P_NETDEAD_INFO
@@ -0,0 +1,120 @@
+
+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
new file mode 100644
index 0000000..d0cdf41
--- /dev/null
+++ b/doc/sphinx/man/props/P_NEVERDROP
@@ -0,0 +1,50 @@
+
+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
new file mode 100644
index 0000000..fc568ff
--- /dev/null
+++ b/doc/sphinx/man/props/P_NEVER_CLEAN
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..7cb61c7
--- /dev/null
+++ b/doc/sphinx/man/props/P_NEWSKILLS
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..6992a32
--- /dev/null
+++ b/doc/sphinx/man/props/P_NEXT_DEATH_SEQUENCE
@@ -0,0 +1,68 @@
+
+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
new file mode 100644
index 0000000..6a9eea3
--- /dev/null
+++ b/doc/sphinx/man/props/P_NEXT_DISABLE_ATTACK
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..27f6c70
--- /dev/null
+++ b/doc/sphinx/man/props/P_NOBUY
@@ -0,0 +1,23 @@
+
+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
new file mode 100644
index 0000000..15d5de2
--- /dev/null
+++ b/doc/sphinx/man/props/P_NOCORPSE
@@ -0,0 +1,51 @@
+
+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
new file mode 100644
index 0000000..a3407c7
--- /dev/null
+++ b/doc/sphinx/man/props/P_NODRINK_MSG
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..786cdea
--- /dev/null
+++ b/doc/sphinx/man/props/P_NODROP
@@ -0,0 +1,60 @@
+
+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
new file mode 100644
index 0000000..d195c5e
--- /dev/null
+++ b/doc/sphinx/man/props/P_NOFOOD_MSG
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..17a6248
--- /dev/null
+++ b/doc/sphinx/man/props/P_NOGET
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..de7d8e8
--- /dev/null
+++ b/doc/sphinx/man/props/P_NOINSERT_MSG
@@ -0,0 +1,65 @@
+
+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
new file mode 100644
index 0000000..d2cd164
--- /dev/null
+++ b/doc/sphinx/man/props/P_NOLEAVE_MSG
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..42e51d1
--- /dev/null
+++ b/doc/sphinx/man/props/P_NOMAGIC
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..6141be3
--- /dev/null
+++ b/doc/sphinx/man/props/P_NOSELL
@@ -0,0 +1,50 @@
+
+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
new file mode 100644
index 0000000..3a143a4
--- /dev/null
+++ b/doc/sphinx/man/props/P_NO_ASCII_ART
@@ -0,0 +1,35 @@
+
+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
new file mode 100644
index 0000000..9ca4c95
--- /dev/null
+++ b/doc/sphinx/man/props/P_NO_ATTACK
@@ -0,0 +1,99 @@
+
+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
new file mode 100644
index 0000000..ae2adf2
--- /dev/null
+++ b/doc/sphinx/man/props/P_NO_BAD
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..962186c
--- /dev/null
+++ b/doc/sphinx/man/props/P_NO_GLOBAL_ATTACK
@@ -0,0 +1,33 @@
+
+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
new file mode 100644
index 0000000..677f9c8
--- /dev/null
+++ b/doc/sphinx/man/props/P_NO_PARA_TRANS
@@ -0,0 +1,30 @@
+
+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
new file mode 100644
index 0000000..3cc88c1
--- /dev/null
+++ b/doc/sphinx/man/props/P_NO_PLAYERS
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..cc672e3
--- /dev/null
+++ b/doc/sphinx/man/props/P_NO_REGENERATION
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..49cfee5
--- /dev/null
+++ b/doc/sphinx/man/props/P_NO_SCORE
@@ -0,0 +1,73 @@
+
+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
new file mode 100644
index 0000000..f8c2f33
--- /dev/null
+++ b/doc/sphinx/man/props/P_NO_STD_DRINK
@@ -0,0 +1,37 @@
+
+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
new file mode 100644
index 0000000..1c6de77
--- /dev/null
+++ b/doc/sphinx/man/props/P_NO_TPORT
@@ -0,0 +1,30 @@
+
+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
new file mode 100644
index 0000000..cd1073a
--- /dev/null
+++ b/doc/sphinx/man/props/P_NO_TRAVELING
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..b16c4ab
--- /dev/null
+++ b/doc/sphinx/man/props/P_NO_XP
@@ -0,0 +1,65 @@
+
+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
new file mode 100644
index 0000000..60651d8
--- /dev/null
+++ b/doc/sphinx/man/props/P_NPC
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..3c358ef
--- /dev/null
+++ b/doc/sphinx/man/props/P_NPC_FASTHEAL
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..a3bf299
--- /dev/null
+++ b/doc/sphinx/man/props/P_NR_HANDS
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..773a80d
--- /dev/null
+++ b/doc/sphinx/man/props/P_ORAKEL
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..53243c2
--- /dev/null
+++ b/doc/sphinx/man/props/P_ORIG_FILE_NAME
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..e44a06d
--- /dev/null
+++ b/doc/sphinx/man/props/P_ORIG_NAME
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..0a7f416
--- /dev/null
+++ b/doc/sphinx/man/props/P_PARA
@@ -0,0 +1,73 @@
+
+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
new file mode 100644
index 0000000..40ddecd
--- /dev/null
+++ b/doc/sphinx/man/props/P_PARRY
@@ -0,0 +1,47 @@
+
+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
new file mode 100644
index 0000000..9ee60aa
--- /dev/null
+++ b/doc/sphinx/man/props/P_PARRY_WEAPON
@@ -0,0 +1,30 @@
+
+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
new file mode 100644
index 0000000..eab38d5
--- /dev/null
+++ b/doc/sphinx/man/props/P_PEACE_HISTORY
@@ -0,0 +1,62 @@
+
+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
new file mode 100644
index 0000000..373c516
--- /dev/null
+++ b/doc/sphinx/man/props/P_PERM_STRING
@@ -0,0 +1,24 @@
+
+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
new file mode 100644
index 0000000..76b2760
--- /dev/null
+++ b/doc/sphinx/man/props/P_PICK_MSG
@@ -0,0 +1,78 @@
+
+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
new file mode 100644
index 0000000..edb0123
--- /dev/null
+++ b/doc/sphinx/man/props/P_PILE_NAME
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..ce0c22d
--- /dev/null
+++ b/doc/sphinx/man/props/P_PLAYER_LIGHT
@@ -0,0 +1,44 @@
+
+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
new file mode 100644
index 0000000..eed829f
--- /dev/null
+++ b/doc/sphinx/man/props/P_PLURAL
@@ -0,0 +1,58 @@
+
+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
new file mode 100644
index 0000000..2ab5dc1
--- /dev/null
+++ b/doc/sphinx/man/props/P_POISON
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..079efd9
--- /dev/null
+++ b/doc/sphinx/man/props/P_POISON_DELAY
@@ -0,0 +1,25 @@
+
+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
new file mode 100644
index 0000000..a6bdf16
--- /dev/null
+++ b/doc/sphinx/man/props/P_PORTIONS
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..975a884
--- /dev/null
+++ b/doc/sphinx/man/props/P_POST
@@ -0,0 +1,82 @@
+
+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
new file mode 100644
index 0000000..0df158f
--- /dev/null
+++ b/doc/sphinx/man/props/P_POTIONROOMS
@@ -0,0 +1,35 @@
+
+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
new file mode 100644
index 0000000..ad0a469
--- /dev/null
+++ b/doc/sphinx/man/props/P_PRAY_ROOM
@@ -0,0 +1,54 @@
+
+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
new file mode 100644
index 0000000..6b629aa
--- /dev/null
+++ b/doc/sphinx/man/props/P_PREFERED_ENEMY
@@ -0,0 +1,41 @@
+
+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
new file mode 100644
index 0000000..1580b5e
--- /dev/null
+++ b/doc/sphinx/man/props/P_PRESAY
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..1ad6807
--- /dev/null
+++ b/doc/sphinx/man/props/P_PREVENT_PILE
@@ -0,0 +1,34 @@
+
+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
new file mode 100644
index 0000000..099e592
--- /dev/null
+++ b/doc/sphinx/man/props/P_PRE_INFO
@@ -0,0 +1,86 @@
+
+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
new file mode 100644
index 0000000..267437e
--- /dev/null
+++ b/doc/sphinx/man/props/P_PROMPT
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..8618009
--- /dev/null
+++ b/doc/sphinx/man/props/P_PUB_NOT_ON_MENU
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..55c4230
--- /dev/null
+++ b/doc/sphinx/man/props/P_PUB_NO_KEEPER
@@ -0,0 +1,37 @@
+
+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
new file mode 100644
index 0000000..9510b07
--- /dev/null
+++ b/doc/sphinx/man/props/P_PUB_NO_MONEY
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..7eaede7
--- /dev/null
+++ b/doc/sphinx/man/props/P_PUB_UNAVAILABLE
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..05ead3b
--- /dev/null
+++ b/doc/sphinx/man/props/P_PURSUERS
@@ -0,0 +1,29 @@
+
+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
new file mode 100644
index 0000000..65624ce
--- /dev/null
+++ b/doc/sphinx/man/props/P_PUT_MSG
@@ -0,0 +1,79 @@
+
+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
new file mode 100644
index 0000000..9840586
--- /dev/null
+++ b/doc/sphinx/man/props/P_QP
@@ -0,0 +1,29 @@
+
+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
new file mode 100644
index 0000000..a103eaf
--- /dev/null
+++ b/doc/sphinx/man/props/P_QUALITY
@@ -0,0 +1,57 @@
+
+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
new file mode 100644
index 0000000..84fe435
--- /dev/null
+++ b/doc/sphinx/man/props/P_QUESTS
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..135954b
--- /dev/null
+++ b/doc/sphinx/man/props/P_QUEST_ITEM
@@ -0,0 +1,73 @@
+
+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
new file mode 100644
index 0000000..c6aebc7
--- /dev/null
+++ b/doc/sphinx/man/props/P_RACE
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..2a13577
--- /dev/null
+++ b/doc/sphinx/man/props/P_RACESTRING
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..ca1f576
--- /dev/null
+++ b/doc/sphinx/man/props/P_RACE_DESCRIPTION
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..2fabc63
--- /dev/null
+++ b/doc/sphinx/man/props/P_RANGE
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..06a7598
--- /dev/null
+++ b/doc/sphinx/man/props/P_READ_DETAILS
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..8c69c89
--- /dev/null
+++ b/doc/sphinx/man/props/P_READ_NEWS
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..39c196a
--- /dev/null
+++ b/doc/sphinx/man/props/P_REAL_RACE
@@ -0,0 +1,95 @@
+
+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
new file mode 100644
index 0000000..9187a49
--- /dev/null
+++ b/doc/sphinx/man/props/P_REFERENCE_OBJECT
@@ -0,0 +1,41 @@
+
+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
new file mode 100644
index 0000000..072bdab
--- /dev/null
+++ b/doc/sphinx/man/props/P_REJECT
@@ -0,0 +1,72 @@
+
+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
new file mode 100644
index 0000000..f5c2232
--- /dev/null
+++ b/doc/sphinx/man/props/P_REMOVE_FUNC
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..78a1357
--- /dev/null
+++ b/doc/sphinx/man/props/P_REMOVE_MSG
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..bbd4bbe
--- /dev/null
+++ b/doc/sphinx/man/props/P_RESET_LIFETIME
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..48e476f
--- /dev/null
+++ b/doc/sphinx/man/props/P_RESISTANCE
@@ -0,0 +1,61 @@
+
+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
new file mode 100644
index 0000000..2a3322e
--- /dev/null
+++ b/doc/sphinx/man/props/P_RESISTANCE_MODIFIER
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..4a93f08
--- /dev/null
+++ b/doc/sphinx/man/props/P_RESISTANCE_STRENGTHS
@@ -0,0 +1,114 @@
+
+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
new file mode 100644
index 0000000..a1764b9
--- /dev/null
+++ b/doc/sphinx/man/props/P_RESTRICTIONS
@@ -0,0 +1,163 @@
+
+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
new file mode 100644
index 0000000..3486458
--- /dev/null
+++ b/doc/sphinx/man/props/P_ROOM_MSG
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..22e894e
--- /dev/null
+++ b/doc/sphinx/man/props/P_ROOM_TYPE
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..1ffac9d
--- /dev/null
+++ b/doc/sphinx/man/props/P_SB_SPELLS
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..e54ee8b
--- /dev/null
+++ b/doc/sphinx/man/props/P_SCREENSIZE
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..69c97d6
--- /dev/null
+++ b/doc/sphinx/man/props/P_SECOND
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..dd2c68a
--- /dev/null
+++ b/doc/sphinx/man/props/P_SECOND_MARK
@@ -0,0 +1,31 @@
+
+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
new file mode 100644
index 0000000..8ec02e7
--- /dev/null
+++ b/doc/sphinx/man/props/P_SEERDOORS
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..12f062b
--- /dev/null
+++ b/doc/sphinx/man/props/P_SEERDOOR_ALLOWED
@@ -0,0 +1,27 @@
+
+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
new file mode 100644
index 0000000..c1e8051
--- /dev/null
+++ b/doc/sphinx/man/props/P_SENSITIVE
@@ -0,0 +1,154 @@
+
+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
new file mode 100644
index 0000000..168c15b
--- /dev/null
+++ b/doc/sphinx/man/props/P_SENSITIVE_ATTACK
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..418f9a1
--- /dev/null
+++ b/doc/sphinx/man/props/P_SENSITIVE_INVENTORY
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..627a582
--- /dev/null
+++ b/doc/sphinx/man/props/P_SENSITIVE_INVENTORY_TRIGGER
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..9339847
--- /dev/null
+++ b/doc/sphinx/man/props/P_SHOOTING_AREA
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..6345d76
--- /dev/null
+++ b/doc/sphinx/man/props/P_SHOOTING_WC
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..49b2603
--- /dev/null
+++ b/doc/sphinx/man/props/P_SHORT
@@ -0,0 +1,60 @@
+
+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
new file mode 100644
index 0000000..46f0236
--- /dev/null
+++ b/doc/sphinx/man/props/P_SHORT_CWD
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..b6cf580
--- /dev/null
+++ b/doc/sphinx/man/props/P_SHOWEMAIL
@@ -0,0 +1,23 @@
+
+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
new file mode 100644
index 0000000..94552dd
--- /dev/null
+++ b/doc/sphinx/man/props/P_SHOW_ALIAS_PROCESSING
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..0e00886
--- /dev/null
+++ b/doc/sphinx/man/props/P_SHOW_EXITS
@@ -0,0 +1,31 @@
+
+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
new file mode 100644
index 0000000..e982154
--- /dev/null
+++ b/doc/sphinx/man/props/P_SHOW_INV
@@ -0,0 +1,32 @@
+
+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
new file mode 100644
index 0000000..c19c49f
--- /dev/null
+++ b/doc/sphinx/man/props/P_SHOW_MSG
@@ -0,0 +1,69 @@
+
+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
new file mode 100644
index 0000000..6e18f0c
--- /dev/null
+++ b/doc/sphinx/man/props/P_SIBLINGS
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..aa311f3
--- /dev/null
+++ b/doc/sphinx/man/props/P_SIZE
@@ -0,0 +1,50 @@
+
+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
new file mode 100644
index 0000000..492cbbe
--- /dev/null
+++ b/doc/sphinx/man/props/P_SKILLS
@@ -0,0 +1,30 @@
+
+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
new file mode 100644
index 0000000..066bd78
--- /dev/null
+++ b/doc/sphinx/man/props/P_SKILL_ATTRIBUTES
@@ -0,0 +1,69 @@
+
+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
new file mode 100644
index 0000000..6bfcad3
--- /dev/null
+++ b/doc/sphinx/man/props/P_SKILL_ATTRIBUTE_OFFSETS
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..0098bd8
--- /dev/null
+++ b/doc/sphinx/man/props/P_SMELLS
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..340dde2
--- /dev/null
+++ b/doc/sphinx/man/props/P_SNOOPFLAGS
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..520265b
--- /dev/null
+++ b/doc/sphinx/man/props/P_SOUNDS
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..fa30cb1
--- /dev/null
+++ b/doc/sphinx/man/props/P_SP
@@ -0,0 +1,37 @@
+
+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
new file mode 100644
index 0000000..9b3f63c
--- /dev/null
+++ b/doc/sphinx/man/props/P_SPECIAL_DETAILS
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..3f2a7a5
--- /dev/null
+++ b/doc/sphinx/man/props/P_SPECIAL_EXITS
@@ -0,0 +1,51 @@
+
+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
new file mode 100644
index 0000000..1a3e5a2
--- /dev/null
+++ b/doc/sphinx/man/props/P_SPELLRATE
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..647daf4
--- /dev/null
+++ b/doc/sphinx/man/props/P_SPELLS
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..aa74360
--- /dev/null
+++ b/doc/sphinx/man/props/P_SP_DELAY
@@ -0,0 +1,23 @@
+
+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
new file mode 100644
index 0000000..fd80124
--- /dev/null
+++ b/doc/sphinx/man/props/P_START_HOME
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..7c66296
--- /dev/null
+++ b/doc/sphinx/man/props/P_STD_OBJECT
@@ -0,0 +1,59 @@
+
+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
new file mode 100644
index 0000000..8a9afd9
--- /dev/null
+++ b/doc/sphinx/man/props/P_STORE_CONSUME
@@ -0,0 +1,69 @@
+
+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
new file mode 100644
index 0000000..1b38b7e
--- /dev/null
+++ b/doc/sphinx/man/props/P_STRETCH_TIME
@@ -0,0 +1,34 @@
+
+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
new file mode 100644
index 0000000..83515d7
--- /dev/null
+++ b/doc/sphinx/man/props/P_SUBGUILD_TITLE
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..a796fb5
--- /dev/null
+++ b/doc/sphinx/man/props/P_SYNTAX_HELP
@@ -0,0 +1,62 @@
+
+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
new file mode 100644
index 0000000..614320f
--- /dev/null
+++ b/doc/sphinx/man/props/P_TARGET_AREA
@@ -0,0 +1,95 @@
+
+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
new file mode 100644
index 0000000..4f853e8
--- /dev/null
+++ b/doc/sphinx/man/props/P_TEAM
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..b57a276
--- /dev/null
+++ b/doc/sphinx/man/props/P_TEAM_ASSOC_MEMBERS
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..b7993e7
--- /dev/null
+++ b/doc/sphinx/man/props/P_TEAM_ATTACK_CMD
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..0e8c45f
--- /dev/null
+++ b/doc/sphinx/man/props/P_TEAM_AUTOFOLLOW
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..a855035
--- /dev/null
+++ b/doc/sphinx/man/props/P_TEAM_COLORS
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..b4927f3
--- /dev/null
+++ b/doc/sphinx/man/props/P_TEAM_LEADER
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..da89b70
--- /dev/null
+++ b/doc/sphinx/man/props/P_TEAM_NEWMEMBER
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..ba94af4
--- /dev/null
+++ b/doc/sphinx/man/props/P_TEAM_WANTED_ROW
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..90bfacb
--- /dev/null
+++ b/doc/sphinx/man/props/P_TEAM_WIMPY_ROW
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..b781bea
--- /dev/null
+++ b/doc/sphinx/man/props/P_TELNET_RTTIME
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..bf0c765
--- /dev/null
+++ b/doc/sphinx/man/props/P_TESTPLAYER
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..fa7db3f
--- /dev/null
+++ b/doc/sphinx/man/props/P_TIMED_ATTR_MOD
@@ -0,0 +1,78 @@
+
+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
new file mode 100644
index 0000000..7e4ce7d
--- /dev/null
+++ b/doc/sphinx/man/props/P_TIMEZONE
@@ -0,0 +1,23 @@
+
+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
new file mode 100644
index 0000000..555e26a
--- /dev/null
+++ b/doc/sphinx/man/props/P_TITLE
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..c2a40ea
--- /dev/null
+++ b/doc/sphinx/man/props/P_TOO_HEAVY_MSG
@@ -0,0 +1,50 @@
+
+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
new file mode 100644
index 0000000..fd1ffe9
--- /dev/null
+++ b/doc/sphinx/man/props/P_TOO_MANY_MSG
@@ -0,0 +1,50 @@
+
+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
new file mode 100644
index 0000000..baa9cf9
--- /dev/null
+++ b/doc/sphinx/man/props/P_TOTAL_AC
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..f4f0083
--- /dev/null
+++ b/doc/sphinx/man/props/P_TOTAL_LIGHT
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..4e2d009
--- /dev/null
+++ b/doc/sphinx/man/props/P_TOTAL_OBJECTS
@@ -0,0 +1,32 @@
+
+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
new file mode 100644
index 0000000..19349f0
--- /dev/null
+++ b/doc/sphinx/man/props/P_TOTAL_WC
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..bdb72f6
--- /dev/null
+++ b/doc/sphinx/man/props/P_TOTAL_WEIGHT
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..f4345db
--- /dev/null
+++ b/doc/sphinx/man/props/P_TOUCH_DETAILS
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..f2e51a9
--- /dev/null
+++ b/doc/sphinx/man/props/P_TPORT_COST_IN
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..c97c752
--- /dev/null
+++ b/doc/sphinx/man/props/P_TPORT_COST_OUT
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..a3e270d
--- /dev/null
+++ b/doc/sphinx/man/props/P_TRANK_FINDEN
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..56c0558
--- /dev/null
+++ b/doc/sphinx/man/props/P_TRANSPARENT
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..3f9b0d5
--- /dev/null
+++ b/doc/sphinx/man/props/P_TRAVEL_CMDS
@@ -0,0 +1,62 @@
+
+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
new file mode 100644
index 0000000..720e9ec
--- /dev/null
+++ b/doc/sphinx/man/props/P_TRAVEL_INFO
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..0c394d4
--- /dev/null
+++ b/doc/sphinx/man/props/P_TRAY
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..87841fd
--- /dev/null
+++ b/doc/sphinx/man/props/P_TTY
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..8780417
--- /dev/null
+++ b/doc/sphinx/man/props/P_TTY_COLS
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..7289109
--- /dev/null
+++ b/doc/sphinx/man/props/P_TTY_ROWS
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..a43076f
--- /dev/null
+++ b/doc/sphinx/man/props/P_TTY_SHOW
@@ -0,0 +1,35 @@
+
+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
new file mode 100644
index 0000000..5842cb2
--- /dev/null
+++ b/doc/sphinx/man/props/P_TTY_TYPE
@@ -0,0 +1,41 @@
+
+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
new file mode 100644
index 0000000..25a5ed1
--- /dev/null
+++ b/doc/sphinx/man/props/P_UNIT_DECAY_FLAGS
@@ -0,0 +1,90 @@
+
+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
new file mode 100644
index 0000000..e0118c3
--- /dev/null
+++ b/doc/sphinx/man/props/P_UNIT_DECAY_INTERVAL
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..b78a735
--- /dev/null
+++ b/doc/sphinx/man/props/P_UNIT_DECAY_MIN
@@ -0,0 +1,71 @@
+
+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
new file mode 100644
index 0000000..0b4c9a6
--- /dev/null
+++ b/doc/sphinx/man/props/P_UNIT_DECAY_QUOTA
@@ -0,0 +1,69 @@
+
+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
new file mode 100644
index 0000000..0b2e89a
--- /dev/null
+++ b/doc/sphinx/man/props/P_UNWEAR_MSG
@@ -0,0 +1,78 @@
+
+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
new file mode 100644
index 0000000..4466ec0
--- /dev/null
+++ b/doc/sphinx/man/props/P_UNWIELD_FUNC
@@ -0,0 +1,32 @@
+
+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
new file mode 100644
index 0000000..d1d1668
--- /dev/null
+++ b/doc/sphinx/man/props/P_UNWIELD_MSG
@@ -0,0 +1,77 @@
+
+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
new file mode 100644
index 0000000..e93a24b
--- /dev/null
+++ b/doc/sphinx/man/props/P_UNWIELD_TIME
@@ -0,0 +1,33 @@
+
+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
new file mode 100644
index 0000000..b90bd61
--- /dev/null
+++ b/doc/sphinx/man/props/P_USED_HANDS
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..f431e7b
--- /dev/null
+++ b/doc/sphinx/man/props/P_VALID_GUILDS
@@ -0,0 +1,41 @@
+
+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
new file mode 100644
index 0000000..cb48202
--- /dev/null
+++ b/doc/sphinx/man/props/P_VALUE
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..3ff1b3c
--- /dev/null
+++ b/doc/sphinx/man/props/P_VALUE_PER_UNIT
@@ -0,0 +1,29 @@
+
+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
new file mode 100644
index 0000000..52a979c
--- /dev/null
+++ b/doc/sphinx/man/props/P_VARIABLES
@@ -0,0 +1,28 @@
+
+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
new file mode 100644
index 0000000..92de8b7
--- /dev/null
+++ b/doc/sphinx/man/props/P_VISIBLE_GUILD
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..e0e5c83
--- /dev/null
+++ b/doc/sphinx/man/props/P_VISIBLE_SUBGUILD_TITLE
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..8a3d836
--- /dev/null
+++ b/doc/sphinx/man/props/P_VISUALBELL
@@ -0,0 +1,58 @@
+
+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
new file mode 100644
index 0000000..f0e3abb
--- /dev/null
+++ b/doc/sphinx/man/props/P_VULNERABILITY
@@ -0,0 +1,62 @@
+
+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
new file mode 100644
index 0000000..301838e
--- /dev/null
+++ b/doc/sphinx/man/props/P_WAITFOR
@@ -0,0 +1,30 @@
+
+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
new file mode 100644
index 0000000..5e616b7
--- /dev/null
+++ b/doc/sphinx/man/props/P_WAITFOR_FLAGS
@@ -0,0 +1,34 @@
+
+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
new file mode 100644
index 0000000..1d997d8
--- /dev/null
+++ b/doc/sphinx/man/props/P_WAITFOR_REASON
@@ -0,0 +1,35 @@
+
+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
new file mode 100644
index 0000000..639ab61
--- /dev/null
+++ b/doc/sphinx/man/props/P_WANTS_TO_LEARN
@@ -0,0 +1,25 @@
+
+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
new file mode 100644
index 0000000..79742c1
--- /dev/null
+++ b/doc/sphinx/man/props/P_WATER
@@ -0,0 +1,130 @@
+
+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
new file mode 100644
index 0000000..cfa18e4
--- /dev/null
+++ b/doc/sphinx/man/props/P_WC
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..a7f68b2
--- /dev/null
+++ b/doc/sphinx/man/props/P_WEAPON
@@ -0,0 +1,31 @@
+
+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
new file mode 100644
index 0000000..ebeb788
--- /dev/null
+++ b/doc/sphinx/man/props/P_WEAPON_TEACHER
@@ -0,0 +1,29 @@
+
+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
new file mode 100644
index 0000000..d200054
--- /dev/null
+++ b/doc/sphinx/man/props/P_WEAPON_TYPE
@@ -0,0 +1,41 @@
+
+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
new file mode 100644
index 0000000..d288187
--- /dev/null
+++ b/doc/sphinx/man/props/P_WEAR_FUNC
@@ -0,0 +1,44 @@
+
+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
new file mode 100644
index 0000000..69fbf44
--- /dev/null
+++ b/doc/sphinx/man/props/P_WEAR_MSG
@@ -0,0 +1,82 @@
+
+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
new file mode 100644
index 0000000..4c37e46
--- /dev/null
+++ b/doc/sphinx/man/props/P_WEIGHT
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..a4d0506
--- /dev/null
+++ b/doc/sphinx/man/props/P_WEIGHT_PERCENT
@@ -0,0 +1,47 @@
+
+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
new file mode 100644
index 0000000..c777b65
--- /dev/null
+++ b/doc/sphinx/man/props/P_WEIGHT_PER_UNIT
@@ -0,0 +1,29 @@
+
+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
new file mode 100644
index 0000000..26bcff7
--- /dev/null
+++ b/doc/sphinx/man/props/P_WIELDED
@@ -0,0 +1,37 @@
+
+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
new file mode 100644
index 0000000..fbe49a7
--- /dev/null
+++ b/doc/sphinx/man/props/P_WIELD_FUNC
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..fa9dafc
--- /dev/null
+++ b/doc/sphinx/man/props/P_WIELD_MSG
@@ -0,0 +1,74 @@
+
+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
new file mode 100644
index 0000000..d0ba078
--- /dev/null
+++ b/doc/sphinx/man/props/P_WIMPY
@@ -0,0 +1,30 @@
+
+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
new file mode 100644
index 0000000..11bedeb
--- /dev/null
+++ b/doc/sphinx/man/props/P_WIMPY_DIRECTION
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..0bea2ad
--- /dev/null
+++ b/doc/sphinx/man/props/P_WIZ_DEBUG
@@ -0,0 +1,37 @@
+
+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
new file mode 100644
index 0000000..999ab76
--- /dev/null
+++ b/doc/sphinx/man/props/P_WORN
@@ -0,0 +1,63 @@
+
+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
new file mode 100644
index 0000000..649f4e0
--- /dev/null
+++ b/doc/sphinx/man/props/P_XP
@@ -0,0 +1,81 @@
+
+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
new file mode 100644
index 0000000..14ab9a4
--- /dev/null
+++ b/doc/sphinx/man/props/P_X_ATTR_MOD
@@ -0,0 +1,68 @@
+
+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
new file mode 100644
index 0000000..69aafab
--- /dev/null
+++ b/doc/sphinx/man/props/P_X_HEALTH_MOD
@@ -0,0 +1,60 @@
+
+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
new file mode 100644
index 0000000..6f9c7ce
--- /dev/null
+++ b/doc/sphinx/man/props/P_ZAP_MSG
@@ -0,0 +1,41 @@
+
+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
new file mode 100644
index 0000000..1594c4f
--- /dev/null
+++ b/doc/sphinx/man/props/U_REQ
@@ -0,0 +1,83 @@
+
+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
new file mode 100644
index 0000000..0485c9a
--- /dev/null
+++ b/doc/sphinx/man/props/gildenprops/P_GLOVE_FINGERLESS
@@ -0,0 +1,30 @@
+
+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
new file mode 100644
index 0000000..994abad
--- /dev/null
+++ b/doc/sphinx/man/props/gildenprops/P_Z_AUTOSHIELD
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..654c768
--- /dev/null
+++ b/doc/sphinx/man/props/gildenprops/P_Z_INFO
@@ -0,0 +1,73 @@
+
+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
new file mode 100644
index 0000000..cda514a
--- /dev/null
+++ b/doc/sphinx/man/props/gildenprops/P_Z_NO_MATERIAL
@@ -0,0 +1,34 @@
+
+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
new file mode 100644
index 0000000..6cd0024
--- /dev/null
+++ b/doc/sphinx/man/props/gildenprops/P_Z_NO_NOCONN
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..74860f6
--- /dev/null
+++ b/doc/sphinx/man/props/gildenprops/P_Z_NO_SPELL_SUPPORT
@@ -0,0 +1,41 @@
+
+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
new file mode 100644
index 0000000..0d34e98
--- /dev/null
+++ b/doc/sphinx/man/props/gildenprops/kaempferboni
@@ -0,0 +1,270 @@
+
+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
new file mode 100644
index 0000000..83a2fc4
--- /dev/null
+++ b/doc/sphinx/man/props/obsolete/P_BALANCED_WEAPON
@@ -0,0 +1,59 @@
+
+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
new file mode 100644
index 0000000..9a16169
--- /dev/null
+++ b/doc/sphinx/man/props/obsolete/P_DEFAULT_INFO
@@ -0,0 +1,50 @@
+
+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
new file mode 100644
index 0000000..203fb8e
--- /dev/null
+++ b/doc/sphinx/man/props/obsolete/P_EXTRA_LOOK
@@ -0,0 +1,57 @@
+
+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
new file mode 100644
index 0000000..199a878
--- /dev/null
+++ b/doc/sphinx/man/props/obsolete/P_LAST_KILLER
@@ -0,0 +1,37 @@
+
+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
new file mode 100644
index 0000000..f8aea49
--- /dev/null
+++ b/doc/sphinx/man/props/obsolete/P_LAST_PEACE_TIME
@@ -0,0 +1,41 @@
+
+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
new file mode 100644
index 0000000..ed57133
--- /dev/null
+++ b/doc/sphinx/man/props/obsolete/P_LOG_FILE
@@ -0,0 +1,69 @@
+
+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
new file mode 100644
index 0000000..300a766
--- /dev/null
+++ b/doc/sphinx/man/props/obsolete/P_NEXT_SPELL_TIME
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..2331508
--- /dev/null
+++ b/doc/sphinx/man/props/obsolete/P_READ_MSG
@@ -0,0 +1,56 @@
+
+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
new file mode 100644
index 0000000..a556ce6
--- /dev/null
+++ b/doc/sphinx/man/props/obsolete/P_TECHNIQUE
@@ -0,0 +1,70 @@
+
+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
new file mode 100644
index 0000000..6bd5130
--- /dev/null
+++ b/doc/sphinx/man/props/obsolete/P_TMP_ATTACK_HOOK
@@ -0,0 +1,95 @@
+
+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
new file mode 100644
index 0000000..df10409
--- /dev/null
+++ b/doc/sphinx/man/props/obsolete/P_TMP_ATTACK_MOD
@@ -0,0 +1,134 @@
+
+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
new file mode 100644
index 0000000..f29d342
--- /dev/null
+++ b/doc/sphinx/man/props/obsolete/P_TMP_DEFEND_HOOK
@@ -0,0 +1,131 @@
+
+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
new file mode 100644
index 0000000..f4008cb
--- /dev/null
+++ b/doc/sphinx/man/props/obsolete/P_TMP_DIE_HOOK
@@ -0,0 +1,91 @@
+
+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
new file mode 100644
index 0000000..8f1aa77
--- /dev/null
+++ b/doc/sphinx/man/props/obsolete/P_TMP_MOVE_HOOK
@@ -0,0 +1,65 @@
+
+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
new file mode 100644
index 0000000..a8ad089
--- /dev/null
+++ b/doc/sphinx/man/props/skill_info_liste
@@ -0,0 +1,355 @@
+
+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
new file mode 100644
index 0000000..6d9564f
--- /dev/null
+++ b/doc/sphinx/man/sefun.index
@@ -0,0 +1,137 @@
+
+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
new file mode 100644
index 0000000..9e55d69
--- /dev/null
+++ b/doc/sphinx/man/sefun/CountUp
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..a9801ef
--- /dev/null
+++ b/doc/sphinx/man/sefun/_notify_fail
@@ -0,0 +1,35 @@
+
+_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
new file mode 100644
index 0000000..8e3017d
--- /dev/null
+++ b/doc/sphinx/man/sefun/break_string
@@ -0,0 +1,112 @@
+
+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
new file mode 100644
index 0000000..de01e96
--- /dev/null
+++ b/doc/sphinx/man/sefun/broken_count_bits
@@ -0,0 +1,48 @@
+
+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
new file mode 100644
index 0000000..e0e16af
--- /dev/null
+++ b/doc/sphinx/man/sefun/cindent
@@ -0,0 +1,22 @@
+
+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
new file mode 100644
index 0000000..02e02b8
--- /dev/null
+++ b/doc/sphinx/man/sefun/debug_info
@@ -0,0 +1,508 @@
+
+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
new file mode 100644
index 0000000..c3f673a
--- /dev/null
+++ b/doc/sphinx/man/sefun/deep_present
@@ -0,0 +1,40 @@
+
+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
new file mode 100644
index 0000000..dac7dd0
--- /dev/null
+++ b/doc/sphinx/man/sefun/dtime
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..b5b480a
--- /dev/null
+++ b/doc/sphinx/man/sefun/dump_netdead
@@ -0,0 +1,29 @@
+
+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
new file mode 100644
index 0000000..593fb31
--- /dev/null
+++ b/doc/sphinx/man/sefun/enable_commands
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..ddaefce
--- /dev/null
+++ b/doc/sphinx/man/sefun/file_time
@@ -0,0 +1,13 @@
+
+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
new file mode 100644
index 0000000..5930695
--- /dev/null
+++ b/doc/sphinx/man/sefun/find_living
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..7f8f9b1
--- /dev/null
+++ b/doc/sphinx/man/sefun/find_livings
@@ -0,0 +1,49 @@
+
+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
new file mode 100644
index 0000000..8686436
--- /dev/null
+++ b/doc/sphinx/man/sefun/find_netdead
@@ -0,0 +1,46 @@
+
+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
new file mode 100644
index 0000000..048b105
--- /dev/null
+++ b/doc/sphinx/man/sefun/find_player
@@ -0,0 +1,60 @@
+
+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
new file mode 100644
index 0000000..63ea31e
--- /dev/null
+++ b/doc/sphinx/man/sefun/getuuid
@@ -0,0 +1,29 @@
+
+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
new file mode 100644
index 0000000..bd64d73
--- /dev/null
+++ b/doc/sphinx/man/sefun/iso2ascii
@@ -0,0 +1,32 @@
+
+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
new file mode 100644
index 0000000..a3f3cab
--- /dev/null
+++ b/doc/sphinx/man/sefun/log_file
@@ -0,0 +1,59 @@
+
+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
new file mode 100644
index 0000000..8e6cfdd
--- /dev/null
+++ b/doc/sphinx/man/sefun/lowerchar
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..a483224
--- /dev/null
+++ b/doc/sphinx/man/sefun/lowerstring
@@ -0,0 +1,45 @@
+
+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
new file mode 100644
index 0000000..9aa90f2
--- /dev/null
+++ b/doc/sphinx/man/sefun/m_copy_delete
@@ -0,0 +1,68 @@
+
+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
new file mode 100644
index 0000000..5cb347b
--- /dev/null
+++ b/doc/sphinx/man/sefun/match_living
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..f48dcc8
--- /dev/null
+++ b/doc/sphinx/man/sefun/md5
@@ -0,0 +1,52 @@
+
+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
new file mode 100644
index 0000000..2bb9d06
--- /dev/null
+++ b/doc/sphinx/man/sefun/mkdirp
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..85b700a
--- /dev/null
+++ b/doc/sphinx/man/sefun/notify_fail
@@ -0,0 +1,107 @@
+
+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
new file mode 100644
index 0000000..bee892e
--- /dev/null
+++ b/doc/sphinx/man/sefun/object_info
@@ -0,0 +1,148 @@
+
+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
new file mode 100644
index 0000000..5d1aace
--- /dev/null
+++ b/doc/sphinx/man/sefun/obsolete/exclude_alist
@@ -0,0 +1,11 @@
+
+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
new file mode 100644
index 0000000..fceac4f
--- /dev/null
+++ b/doc/sphinx/man/sefun/obsolete/remove_alist
@@ -0,0 +1,7 @@
+
+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
new file mode 100644
index 0000000..357e838
--- /dev/null
+++ b/doc/sphinx/man/sefun/old_explode
@@ -0,0 +1,53 @@
+
+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
new file mode 100644
index 0000000..cd43faf
--- /dev/null
+++ b/doc/sphinx/man/sefun/process_call
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..fbc7018
--- /dev/null
+++ b/doc/sphinx/man/sefun/process_string
@@ -0,0 +1,77 @@
+
+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
new file mode 100644
index 0000000..32358ed
--- /dev/null
+++ b/doc/sphinx/man/sefun/query_editing
@@ -0,0 +1,29 @@
+
+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
new file mode 100644
index 0000000..7deccee
--- /dev/null
+++ b/doc/sphinx/man/sefun/query_idle
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..c40c355
--- /dev/null
+++ b/doc/sphinx/man/sefun/query_input_pending
@@ -0,0 +1,27 @@
+
+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
new file mode 100644
index 0000000..76de80f
--- /dev/null
+++ b/doc/sphinx/man/sefun/query_ip_name
@@ -0,0 +1,28 @@
+
+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
new file mode 100644
index 0000000..d09bc88
--- /dev/null
+++ b/doc/sphinx/man/sefun/query_ip_number
@@ -0,0 +1,43 @@
+
+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
new file mode 100644
index 0000000..8af988f
--- /dev/null
+++ b/doc/sphinx/man/sefun/query_limits
@@ -0,0 +1,82 @@
+
+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
new file mode 100644
index 0000000..de4c1e2
--- /dev/null
+++ b/doc/sphinx/man/sefun/query_mud_port
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..528ae56
--- /dev/null
+++ b/doc/sphinx/man/sefun/query_next_reset
@@ -0,0 +1,47 @@
+
+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
new file mode 100644
index 0000000..bfb8b55
--- /dev/null
+++ b/doc/sphinx/man/sefun/query_once_interactive
@@ -0,0 +1,21 @@
+
+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
new file mode 100644
index 0000000..aadf109
--- /dev/null
+++ b/doc/sphinx/man/sefun/query_shadowing
@@ -0,0 +1,38 @@
+
+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
new file mode 100644
index 0000000..94e598a
--- /dev/null
+++ b/doc/sphinx/man/sefun/query_snoop
@@ -0,0 +1,26 @@
+
+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
new file mode 100644
index 0000000..fe01fbd
--- /dev/null
+++ b/doc/sphinx/man/sefun/query_wiz_grp
@@ -0,0 +1,34 @@
+
+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
new file mode 100644
index 0000000..3645035
--- /dev/null
+++ b/doc/sphinx/man/sefun/query_wiz_level
@@ -0,0 +1,70 @@
+
+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
new file mode 100644
index 0000000..1756890
--- /dev/null
+++ b/doc/sphinx/man/sefun/read_data
@@ -0,0 +1,34 @@
+
+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
new file mode 100644
index 0000000..3804be3
--- /dev/null
+++ b/doc/sphinx/man/sefun/replace_personal
@@ -0,0 +1,113 @@
+
+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
new file mode 100644
index 0000000..631252d
--- /dev/null
+++ b/doc/sphinx/man/sefun/restore_object
@@ -0,0 +1,31 @@
+
+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
new file mode 100644
index 0000000..fc8175f
--- /dev/null
+++ b/doc/sphinx/man/sefun/save_object
@@ -0,0 +1,35 @@
+
+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
new file mode 100644
index 0000000..7ddf43d
--- /dev/null
+++ b/doc/sphinx/man/sefun/send_room
@@ -0,0 +1,42 @@
+
+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
new file mode 100644
index 0000000..a304181
--- /dev/null
+++ b/doc/sphinx/man/sefun/set_heart_beat
@@ -0,0 +1,41 @@
+
+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
new file mode 100644
index 0000000..b9dfc9c
--- /dev/null
+++ b/doc/sphinx/man/sefun/set_light
@@ -0,0 +1,32 @@
+
+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
new file mode 100644
index 0000000..e588e6e
--- /dev/null
+++ b/doc/sphinx/man/sefun/set_living_name
@@ -0,0 +1,41 @@
+
+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
new file mode 100644
index 0000000..caecca2
--- /dev/null
+++ b/doc/sphinx/man/sefun/set_object_heart_beat
@@ -0,0 +1,34 @@
+
+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
new file mode 100644
index 0000000..ef3b10e
--- /dev/null
+++ b/doc/sphinx/man/sefun/sha1
@@ -0,0 +1,44 @@
+
+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
new file mode 100644
index 0000000..2b7032c
--- /dev/null
+++ b/doc/sphinx/man/sefun/shadow
@@ -0,0 +1,162 @@
+
+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
new file mode 100644
index 0000000..0d38abb
--- /dev/null
+++ b/doc/sphinx/man/sefun/shout
@@ -0,0 +1,93 @@
+
+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
new file mode 100644
index 0000000..4acd1a2
--- /dev/null
+++ b/doc/sphinx/man/sefun/time2string
@@ -0,0 +1,75 @@
+
+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
new file mode 100644
index 0000000..b25c07c
--- /dev/null
+++ b/doc/sphinx/man/sefun/update_actions
@@ -0,0 +1,63 @@
+
+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
new file mode 100644
index 0000000..416c90d
--- /dev/null
+++ b/doc/sphinx/man/sefun/upperstring
@@ -0,0 +1,39 @@
+
+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
new file mode 100644
index 0000000..4c007a3
--- /dev/null
+++ b/doc/sphinx/man/sefun/uptime
@@ -0,0 +1,37 @@
+
+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
new file mode 100644
index 0000000..f81b9b8
--- /dev/null
+++ b/doc/sphinx/man/sefun/wizlist
@@ -0,0 +1,84 @@
+
+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
new file mode 100644
index 0000000..0c86434
--- /dev/null
+++ b/doc/sphinx/man/sefun/wizlist_info
@@ -0,0 +1,58 @@
+
+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
new file mode 100644
index 0000000..b8f0d4f
--- /dev/null
+++ b/doc/sphinx/man/sefun/write_data
@@ -0,0 +1,39 @@
+
+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)