P_VALUE Obsolete

Bild: Münzen

Hallo,

P_VALUE war der Geldwert eines Objektes in Kreuzer. Dieser wurde in den Läden benutzt, um den Verkaufspreis zu berechen.

Statt P_VALUE gibt es jetzt P_BUY_VALUE. Diese neue Propertiy entspricht zu 100% dem alten P_VALUE.

Nur umbenennen macht natürlich keinen Sinn… deshalb gibt es jetzt eine zweite Property: P_SELL_VALUE. Sie kann den Preis in Kreuzer enthalten, die ein Laden als Verkaufspreis ansetzen soll.

Dabei muss P_SELL_VALUE ÜBER dem normalen Verkaufspreis im Laden liegen, ansonsten wird es ignoriert. Daraus folgt: mit P_SELL_VALUE kann man Objekte nur teurer, aber niemals billiger machen.

LG, It@Efferdland

Neues MUD!

Bild: Baum

Moin,

damit hier mal etwas passiert in Richtung Efferdland habe ich heute die alte AnderLand-Seite entfernt und auf die neue Efferdland Webseite umgeleitet. Da könnt ihr bei den Neuigkeiten sehen, was so im Efferdland entwickelt wird.

Kritik, Anregungen etc. zur Webseite entweder im AL in die Zeitung setzen, oder Torin oder mich anschreiben/ansprechen.

Für die Leute, die es noch nicht wissen: Wir werden bald einen Neuanfang machen und in diesem Zuge wird das AnderLand in Efferdland umbenannt. Geplant ist das ganze Anfang 2020. Vorher wird man sich auch im Efferdland nicht anmelden koennen.

Wer bei der Efferdland Webseite mitmachen möchte (WordPress) kann sich gerne bei mir oder Torin melden. Vor allem müsste das Lexikon:

 https://efferdland.de/das-efferdland-lexikon/

nach und nach erweitert werden.

Zudem biete ich hier noch einmal für die Leute, die Ideen in das Mud einbringen möchten, eine Nextcloud Zugang an. Einfach Torin oder mich anschreiben.

Weiter Anpassungen:

Das Efferdland ist auch unter folgenden Addressen zu erreichen:
 efferdland.de
 el.mudden.de
 efferdland.mudden.de

LG, It@Efferdland

P_TERRAIN & P_ENVIRONMENT

Bild: Berge

Jeder Raum im Efferdland muss bestimmte Elemente enthalten, damit er in das Konzept passt. Wichtige Elemente im Efferdland sind z.B. P_ENVIRONMENT und P_TERRAIN, die (fast) immer gesetzt werden müssen.

P_TERRAIN:

P_TERRAIN beschreibt den Landschaftstypen und ist definiert in /sys/room/terrain.h. Das Setzen dieser Property ist natürlich nur ausserhalb von Gebäuden sinnvoll.

Folgende Terrain Typen gibt es im Efferdland

T_AIRin der Luftz.B. in einem Ballon
T_UNDER_WATERunter Wasserbeim Tauchen
T_AT_WATERam Wasserz.B. Flussufer
T_IN_WATERim Wasserschwimmend
T_HILLauf einem Hügel
T_MOUNTAINim Gebirge
T_PLAINin einer Ebene
T_SWAMPim Sumpf
T_DESERTin einer Wüste
T_FORESTWaldgebiet
T_URBANStadtgebiet
T_FLOODPLAINim Auenegebieteines Flusses…
T_GARDENim Gartenauch Parks u.ä.
T_MOORim Moor
T_UNDERGROUNDim UntergrundHöhlen, Gänge, Tunnel…
T_JUNGLEim Dschungelauch Urwälder
T_COPSEim Unterholz
T_ICEEislandschaft
T_MEADOWWeisen / Wiesen
T_VELDin einer Steppe
T_VILLAGEin einem Dorf
T_POISENDgiftige Umgebungz.B. im Vulkankrater
T_PATHauf einem Pfad
T_TRACKauf einem Weg
T_ROADauf einer Strasse

Es können auch mehrere Terrains gleichzeitig gesetzt werden. Dies ist nötig, wenn man sich z.B. auf einen Weg in einem Dorf befindet. Die Syntax hierfür ist: SetProp(P_TERRAIN, T_TRACK | T_VILLAGE);

Wie gesagt ist P_TERRAIN zwingend zu setzen! Diese Property sollte ernst genommen werden und es ist untersagt, hier irgendwelchen Mumpitz einzutragen!

P_ENVIRONMENT:

Ähnlich wichtig ist die Property P_ENVIRONMENT. Sie beschreibt die Eigenschaften einer Umgebung, z.B. Temperatur. Höhe über NN und Windgeschwindigkeiten. Auch diese Property muss in jedem Raum gesetzt werden. P_ENVIRONMENT ist definiert in /sys/environment.h

P_ENVIRONMENT ist ein Mapping und kann folgende Werte enthalten:

ENV_TEMPERATURETemperaturin Grad Celsius
ENV_ENVSPEEDUmgebungs Geschwindigkeit1 Beaufort (Wertebereich: 1-12), unter Wasser: Strömung
ENV_ALTITUDEHöheüber NN in Meter
ENV_WATERWassertiefein Meter
ENV_HUMIDITYLuftfeuchtigkeitIn %

Aus ENV_TEMPERATURE und ENV_SPEED wird die Property P_WINDCHILL
berechnet, die nur abfragbar ist und die gefühlte Temperatur enthält. Hier ein Beispiel, wie man P_ENVIRONMENT richtig setzt.

SetProp(P_ENVIRONMENT,
([
  ENV_ENVSPEED: 3,     // Windstärke 3
  ENV_TEMPERAURE: -5   // -5 Grad Celsius
  ENV_ALTITUDE: 300    // Meter Höhe 
]));

Schreibt man P_ENVIRONMENT in ein STD-File und möchte man z.B. nur die Temperatur ändern, weil man z.B. immer weiter in den kalten Norden geht, muss man nicht die komplette Property neu setzen, sondern nur den Wert, den man ändern möchte:

// So ändert man nur die Temperatur und lässt alle anderen Werte unberührt:
SetProp(P_ENVIRONMENT,
([
  ENV_TEMPERATURE: -10,
]));

P_ENVIRONMENT enthält von Haus aus STD-Werte:

ENV_ENVSPEEDWindgeschwindigkeitIm Raum: 0
Draußen: 1
ENV_HUMIDITYLuftfeuchtigkeitIm Raum: 50%
Draußen: 60%
ENV_TEMPERATURETemperatur.Im, Raum: 20
Draußen: 15
ENV_ALTITUDEHöhe3m über NN

LG, It@Efferdland

Neue Ebene -d

Bild: Fehler

Hallo,

in der Region Work kann jeder interessierte Magier seine Gebiete entwickeln. Vorteil von /d/work/ ist dabei, dass (im Gegensatz zu /players/) nichts an den Pfaden geändert werden muss, wenn man seine Arbeit nach Fertigstellung in eine öffentliche Region verschiebt. Das erspart viel Arbeit.

Die Debugausgaben für alle Regionen landen im Normalfall auf der Ebene -D (Debug). Da es in der Entwicklungsregion /work/ naturgemäß sehr viele Bugs gibt, gibt er hierfür nun eine eigene Debug Ebene: -d.

Gruß, – It –

Suchen und Finden im Spieler

Bild: Fehler

Liebe Mitmagier,

in diesem Beitrag geht es um Suchen und Finden von Gegenständen in Spielern.

Immer wieder kommen wir zu einem Punkt, an dem wir etwas im Spieler (oder NPC oder Raum) suchen und ggf. auch finden / identifizieren müssen.
Dabei gibt es verschiedene Vorgehensweisen, die mehr und weniger gut sind.
Ich möchte hier ein paar vorstellen:

Angenommen, ich suche im Spieler einen bestimmten Gegenstand mit der ID
“\nQuestFlasche” und dem Pfad “/d/gebirge/hoehle/obj/flasche.c”.

  1. SEHR schlecht, nicht nachmachen!
object* fl = all_inventory(spieler);

  if ( !fl || !sizeof(fl) )
   {
    tell_object(spieler,"Du hast leider keine passende Flasche dabei.\n");
    return 1;
   }
  object flasche;
  for ( i=sizeof(fl)-1; i>=0; i-- )
   if ( fl[i]->id("\nQuestFlasche") )
    {
     flasche = fl[i];
     break;
    }
   ...

Warum ist das schlecht? Aus verschiedenen Gründen:

  • Um etwas in einem Spieler zu finden brauchen wir all_inventory()
    grundsätzlich nicht explizit.
  • for() ist langsamer als foreach().
  • id() ist generell teuer, innerhalb einer Schleife ist es noch teurer. 🙂
  1. FALLS man an einer Schleife festhalten will (warum auch immer), dann
    bitte:
  int flag = 0;
  object flasche;

  foreach ( object flasche : all_inventory(spieler) )
   if ( "/d/gebirge/hoehle/obj/flasche" == load_name(flasche) )
    {
     flag = 1;
     break;
    }

  if ( !flag )
   {
    tell_object(spieler,"Du hast leider keine passende Flasche dabei.\n");
    return 1;
   }
  ...
  1. Am besten jedoch mit present_clone() und dem Pfad arbeiten:
  object flasche = present_clone("/d/gebirge/hoehle/obj/flasche",spieler);
/ bzw. noch besser, weil flexibler:
/ object flasche = present_clone(OBJ"flasche",spieler);

  if ( !objectp(flasche) )
   {
    tell_object(spieler,"Du hast leider keine passende Flasche dabei.\n");
    return 1;
   }
  ...

Bis bald!

Gruß, Torin