STANDARDOBJEKT FUER EINEN LADEN
Wunderland MUDlib
BENUTZUNG
inherit "laden";
#include <laden.h>
#include <properties.h>
BESCHREIBUNG
Standardobjekt fuer einen Laden. Der Laden regelt das Anzeigen der
Verkaufslisten, den Kauf/Verkauf und die Bezahlung der Gegenstaende.
Es laesst sich festlegen, mit was der Laden handelt, wieviel der
Laden dafuer verlangt oder was er zahlt, ob ein Haendler anwesend
sein muss oder nicht. Zusaetzlich bietet der Laden noch Funktionen
zum Schaetzen des Gegenstandes und zum Testen, ob jemand eine Waffe
benutzen kann oder nicht und zum Feilschen.
PROPERTIES
Grundsaetzlich muessen die normalen Room-Properties gesetzt werden.
Zusaetzlich hat der Laden folgende Properties:
P_STORAGE
Hier gibt man den Raum (als Pfadname) an, der als Lager fuer den
Laden dienen soll. Diese Propertie MUSS IMMER gesetzt werden. Es
existiert ein std/store.c von dem man sein eigenes Lager ableiten
kann. Es ist also neben dem eigentlichen Laden immer noch ein
Lagerraum auf Basis von std/store.c anzulegen.
P_CURRENCY
Enthaelt die verwendete Waehrung (z.B. CT_WUNDERLAND oder
CT_AUSSENWELT). Standardmaessig wird automatisch die
Standardwaehrung der jeweiligen Region benutzt.
P_MAX_CASH
Betrag an Grundeinheiten (WL-Waehrung Bernsteinen), die der Laden
fuer ein Objekt maximal auszahlt. (Default: 1000)
P_MAX_STORE
Gibt an, wieviele gleichartige Objekte der Laden maximal im Lager
haelt. Also X Fackeln oder X Barbarenaexte. (Default: 5)
P_MAX_UNITS
Gibt an, wieviele Objekte eines Units der Laden maximal im Lager
haelt. Also X Edelmetalle oder X Naegel. (Default: 1000)
P_BUYFACTOR
Gibt an, wieviel ein Objekt mehr/weniger als P_VALUE des Objekts
kostet, wenn man es im Laden kauft. Der Laden verlangt also
P_BUYFACTOR * Wert vom Spieler. (Default: 3) Die Propertie kann
auch eine Closure enthalten!
Die Property muss im Store gesetzt werden, nicht im Laden.
P_SELLFACTOR
Gibt an, wieviel ein Objekt mehr/weniger als P_VALUE des Objekts
bringt, wenn man es im Laden verkauft. Der Laden zahlt also
P_SELLFACTOR * Wert an den Spieler. (Default: 1) Der Laden zahlt
jedoch nicht mehr, als er maximal noch Geld hat oder wenn im Lager
schon viele solcher Objekte liegen! Die Propertie kann auch eine
Closure enthalten!
P_TRADE_WITH
Gibt an, mit was der Laden handelt. Man kann hier also bestimmte
´Kategorien´ vorgeben. (Default: T_ALL (alles))
P_TRADE_NOT
Gibt an, mit was der Laden NICHT handeln soll. Im Gegensatz zu
P_TRADE_WITH kann man hier Kategorien ´ausklammern´. Dies setzt
natuerlich voraus, dass sie in P_TRADE_WITH ermoeglicht wurden.
(Default: 0 (nichts wird ausgeklammert));
P_TRADER_NEEDED
Legt fest, ob ein Haendler anwesend sein muss. Ist es auf 1 ge-
setzt, muss ein Objekt mit Id "\ntrader" anwesend sein. Ist es
ein Array aus Strings muss mindestens ein Objekt mit einer Id
aus dem Array im Laden anwesend sein. Ist P_TRADER_NEEDED gesetzt,
aber kein Haendler anwesend, kann man in dem Laden nichts machen.
(Default: 0 (kein Haendler noetig))
P_TRADER_GENDER
Gibt das Geschlecht des Haendlers an. Dieses muss natuerlich mit
dem Haendler uebereinstimmen, so P_TRADER_NEEDED gesetzt ist.
Ansonsten wird ein ´imaginaerer´ Haendler mit dem angegebenen Ge-
schlecht benutzt, um Meldungen usw. auszugeben. (Default: MALE)
P_TRADER_WARNS
Wenn gesetzt, wird der Spieler gewarnt, wenn er Behaelter verkau-
fen will, die noch Gegenstaende enthalten. Wenn nicht gesetzt,
dann nimmt der Laden den Behaelter samt Inhalt entgegen, bezahlt
jedoch nur den Behaelter! Der Rucksack liegt dann samt Inhalt
im Lager und kann auch samt Inhalt wieder gekauft werden. (welch
gut dokumentierter Bug :-) (Default: 1 (Haendler warnt))
P_USE_REAL_CASH
Falls diese Property gesetzt ist, wird fuer den Laden ein mehr oder
weniger (eher weniger) realistisches Geldsystem benutzt. Das be-
deutet, der Haendler hat einen bestimmten Geldbetrag (gespeichert
in der globalen Int-Variable 'Money'). Dieser Betrag wird bei jedem
Verkauf erhoeht (um 80% des vom Spieler bezahlten Betrages) bzw.
beim Kaufen verringert (um 100% der bezahlten Summe). Falls der
Laden einmal kein Geld mehr besitzen sollte, wird er Spieler, die
ihm was verkaufen wollen, darauf hinweisen.
Normalerweise sollte dann der Haendler immer mal (z.B. per 'reset')
Geld 'zugeschoben' bekommen, denn traditionell wird in den Laeden
immer mehr verkauft als gekauft. (Default: 0 (der Laden ist immer
liquid))
P_FBONUS
Gibt den Feilsche-Bonus waehrend des Feilschens an. Doku? Viel-
leicht hilft das Beispiel weiter unten...
FUNKTIONEN
Grundsaetzlich laesst sich das meiste ueber die Properties des Ladens
realisieren. Preisvariationen koennen ueber P_BUYFACTOR und
P_SELLFACTOR recht einfach umgesetzt werden (siehe Manpage). Die
Funktionen get_buy_value(object) und get_sell_value(object) sind
durch Erweiterung von P_BUYFACTOR und P_SELLFACTOR auf Closures ziem-
lich obsolet geworden und werden nicht mehr dokumentiert.
FUNKTIONEN ZUM FEILSCHEN
(von Rince@Wunderland)
Die verbliebenen Funktionen zum Feilschen im Laden zum Ueberschrei-
ben. Damit kann man das Feilschen gilden-, rassenabhaengig machen,
bestimmen, in welchem Masse gefeilscht werden kann und welchen Ein-
fluss ein evtl. Feilsche-Skill hat und bestimmten Spielern/NPCs
Vorteile oder auch Nachteile einraeumen z.b. im Rahmen einer Quest.
get_fcost(int)
get_fnocost(int)
get_scost(int)
get_snocost(int)
Zur Erinnerung, die Spieler koennen in einen Laden Objekte kaufen und
verkaufen. Entweder sie aktzeptieren den 'Fixpreis' der Ware, oder
sie versuchen durch 'feilschen' ein Schnaeppchen zu machen.
Die Syntax fuer das 'feilschende kaufen' ist:
'kaufe feilschend <gegenstand>'
analog fuer das verkaufen:
'verkaufe feilschend <gegenstand/gegenstaende>'
Im Laden laeuft das ganze dann ungefaehr so ab (Bsp. Kaufen):
Zuerst wird der Wert des Objekt berechnet aus P_VALUE des
Objekts*P_BUYFACTOR, um den Verkaufswert des Objektes fest-
zustellen.
Wenn der Spieler nicht feilschend kauft geht es dann ganz
normal weiter, sonst wird danach get_fcost(cost) und
get_scost(cost) aufgerufen.
Die Funktionen sind immer paarweise beschrieben, die erste wird beim
Kauf, die zweite beim Verkauf eines Objektes durch den Spieler.
- get_fcost(int cost)/get_fnocost(int nocost)
Diese Funktionen werden nur beim 'feilschenden' Kauf/Verkauf auf-
gerufen. In Ihnen wird das normale Feilschen, (i.d.R. wohl ein
random(x)) fuer alle Spieler definiert. Im Standardladen sieht das
ganze so aus das der Preis (das wird mit cost/nocost uebergeben)
zufaellig um +-15% schwankt. Rueckgabewert ist der neue Preis.
Achtung! Die Pruefung auf P_MAX_CASH geschieht _vor_ dem
Funktionsaufruf. Das hat zur Folge das der Spieler beim Feilschen
im Glueckfall mehr als P_MAX_CASH erhaelt vom Haendler.
Ein Bsp. in welchen das weibliche Geschlecht 30% Bonus beim
Feilschen bekommt (nur fuer Kauf, fuer Verkauf muesste
get_fnocost() ebenfalls angepast werden):
int get_fcost(int cost)
{
if (cost != 0)
{
// die 'normale' Berechnugn wie im /std/laden.c
cost=cost*((85+random(31))/100.0);
// der Frauen_bonus
if (this_player()->QueryProp(P_GENDER)==FEMALE)
{
cost=cost*1.3;
}
cost=to_int(cost + 0.5);
}
return cost;
}
- get_scost(int cost)/get_snocost(int cost)
Diese Funktionen werden ebenfalls nur beim feilschenden Kauf/
Verkauf aufgerufen. In Ihnen wird ein evtl. Skill der Spieler
beruecksichtigt. Der Skill muss wie ueblich beim Skillmaster
angemeldet werden. Er wird direkt vom Laden aufgerufen via:
// SM ist das Skillmaster-Define aus /sys/living/skills.h
SM->Execute("feilsche", this_player(), 0);
Wenn ihr also einen Skill schreibt, ist _kein_ Kommando das der
Spieler aufrufen kann noetig. Aus der Sicht des Ladens hat der
Skill nur eine einzige Property im Laden zu setzen,
P_FBONUS definiert in /sys/laden.h
P_FBONUS gibt an wie gut der Skill geklappt hat. Keine Aenderung
ist 100(%), 20% besser 120(%), 50% Malus auf den Preis bedeutet
also 50(%). Die Werte von P_FBONUS sind Integerzahlen zwischen
1 und 1000. Es sind im Moment auch noch hoehere Werte erlaubt.
Nochmal ein P_FBONUS von 1000 bedeutet das der Spieler beim
Kaufen nur ein Zehntel des Originalpreises zahlen muss, bzw. beim
Verkaufen den 10fachen Preis erhaelt und dementsprechend bedeutet
ein P_FBONUS von 75 das der Spieler nur 3/4 des Wertes erhaelt,
bzw. 1/4 mehr (also 5/4) zahlen muss. Desweiteren moechte ich
euch bitten, eure Skill mit den Skill der anderen Gilden zu ver-
gleichen, so sollten z.b. die Abenteurer immer besser feilschen
koennen als z.b. die Behueter mit ihrer edlen Gesinnung.
Im folgenden Bsp. ist der Programmierer der Meinung das der Skill
doppelt so hoch gewertet als normal werden soll.
int get_scost(int cost)
{
// erstmal ganz normal...
if (cost != 0)
{
// Der Aufruf des Skills ueber den Skillmaster
// wenn kein Skill da ist wird die Property
// nicht gesetzt, QueryProp liefert also '0'
"/secure/skillmaster"->Execute("feilsche", this_player(), 0);
// so und nun wird der Skill doppelt gewertet, d.h. die
// Property P_FBONUS die der Skill im Laden gesetzt hat
// mit 2 multipliziert.
cost=(QueryProp(P_FBONUS)>0?
cost*(100.0/(2*QueryProp(P_FBONUS))):cost);
// zur erklaerung der Zeile, es wird mit dem ? Operator abge-
// prueft ob der Skill vorhanden, wenn nicht bleiben die
// kosten unveraendert, ansonsten wird der neue Preis ausge-
// rechnet mit Preis=Preis*100/(2*P_FBONUS)
// Prozentrechnung *wah*
// die Konvertierung zurueck zu nem Int
cost=to_int(cost+0.5);
// das Property zuruecksetzen *WICHTIG*
SetProp(P_FBONUS,0);
// noch ne Sicherheitsabfrage
if(!(cost > 0)) cost = 1;
}
return cost;
}
Bei Fragen zum Feilschen bitte an Rince@Wunderland wenden. :-)
BEISPIELE
(/doc/beispiele/bspladen1.c)
VERERBUNGSBAUM
laden
`-std/room
`-std/trade
SIEHE AUCH
room, P_BUYFACTOR, P_SELLFACTOR, P_TRADER_GENDER, P_TRADER_NEEDED,
P_TRADER_WARNS, P_TRADE_WITH, P_TRADE_NOT, P_MAX_CASH, P_MAX_STORE,
P_MAX_UNITS, P_STORAGE, P_COINMASTER, P_USE_REAL_CASH,
P_ITEM_COLUMN_WIDTH, skillmaster(SEC)
|
