| Zesstra | b57d4a8 | 2018-08-28 22:55:48 +0200 | [diff] [blame] | 1 | Virtuelle Items / Objekte |
| 2 | ========================= |
| 3 | |
| 4 | Um ein Objekt genauer beschreiben zu koennen, gibt es einerseits Details an |
| 5 | diesem Objekt. |
| 6 | Andererseits gibt es sog. virtuelle Items (vItems), die detaillierter als |
| 7 | einfache Details beschrieben werden koennen (z.B. mit Geschlecht, Material etc.), ohne wirklich als normales Objekt im Raum zu liegen. Sie koennen auch eigene Details (alle Sinne) haben und sogar selber vItems enthalten. Die vItems werden von untersuche behandelt wie normale Objekte und sind sogar als Referenzobjekt nutzbar. |
| 8 | |
| 9 | Auf Wunsch koennen sie so konfiguriert werden, dass ein vItem nehmbar ist. |
| 10 | Das vItem im Raum und das genommene im Spielerinventar koennen hierbei sogar |
| 11 | unterschiedlich beschrieben sein. Auf diese Weise koennen nehmbare Objekte im |
| 12 | Raum erzeugt werden, die nicht staendig im Raum rumliegen. |
| 13 | |
| 14 | Die vItems koennen dabei grundsaetzlich mit allen Props konfiguriert werden, |
| 15 | die man auch in normalen Objekten setzen kann. Allerdings werden diese Props |
| 16 | nicht alle genutzt bzw. sind sind nicht alle sinnvoll. Beispielsweise sind |
| 17 | kampfrelevante Props im Kontext von vItems bedeutungslos, ebenso solche, die |
| 18 | von speziellem Code genutzt werden, der nicht in /std/container enthalten |
| 19 | ist. (Allerdings kann beim Nehmen eines vItems durchaus ein nicht-standard Objekt (Waffe/Ruestung/etc.) erzeugt werden, welches im Kampf auch ganz normal genutzt werden kann.) |
| 20 | |
| 21 | Wird in einem vItem eine Blueprint angegeben, dient diese auch als Vorlage (Templat), aus der ggf. Properties abgefragt werden, welche nicht im vItem selbst angegeben sind. |
| 22 | |
| 23 | Das Nehmen von vItems ist moeglich, wenn eine Blueprint eingetragen ist, |
| 24 | welche dann geclont werden kann. Hierbei muss man sich dann auch nicht mehr |
| 25 | selber darum kuemmern, ob der Spieler das Objekt tragen kann (und es ggf. |
| 26 | wieder zerstoeren). Die Funktionen von put_and_get.c verarbeiten vItems, |
| 27 | sofern es ein passendes gibt. |
| 28 | Nach dem Nehmen eines vItems ist dieses standardmaessig bis zum naechsten |
| 29 | Reset "weg", d.h. nicht mehr nehmbar (clonbar) und wird auch nicht mehr |
| 30 | gefunden bei untersuche & Co. Fuer den Reset von vItems sind vergleichbare Einstellung wie bei AddItem() moeglich. |
| 31 | |
| 32 | Interagiert Code mit einem vItem, welcher ein Objekt benoetigt, wird |
| 33 | on-the-fly ein Objekt erzeugt. Ist es ein vItem mit Blueprint, wird diese |
| 34 | geclont und mit den konfigurierten Properties des vItems konfiguriert. |
| 35 | Anderenfalls wird ein Proxyobjekt erzeugt und mit den Properties des vItems |
| 36 | konfiguriert, in welchem z.B. lfuns gerufen werden koennen. Hierbei ist das |
| 37 | Proxyobjekt allerdings immer vom Typ /std/container. |
| 38 | |
| 39 | Ein vItem mit Blueprint benutzt (intern) einen Shadow, um Unterschiede |
| 40 | zwischen dem realen Objekt des vItems ("genommener Zustand") und dem vItem im |
| 41 | Raum zu ermoeglichen. |
| 42 | |
| 43 | Interaktion mit bug/typo/etc. |
| 44 | ----------------------------- |
| 45 | |
| 46 | Hat das vitem ein Templat, wird wie gehabt an diesem der Eintrag vorgenommen, |
| 47 | als waere dieses Objekt im Raum. |
| 48 | Hat es kein Templat, wird der Eintrag an dem Objekt vorgenommen, der es |
| 49 | geclont hat. Das wird in aller Regel der Raum/Container sein, der das vItem |
| 50 | beinhaltet. |
| 51 | |