Mover 1

• Mover sind Vobs, die sich nach Aufruf bewegen. Sie werden z.B. genutzt um grosse Eingänge, wie Burgtore mittels einem Gitter öffnen und wieder verschliessen zu können.
• Ihr könnt einen Aufzug bauen, dass ein Npc von Etage A nach Etage B sich transportieren kann,
• eine Zugbrücke herunterlassen,
• Fallen bauen, dass beim laufen in einem Flur eine Falltür nach unten schnappt,
• Spiesse aus dem Boden rammen lassen…. die Möglichkeiten sind schier unerschöpflich…. alles bleibt eurer Phantasie überlassen….

• Für unser Moverbeispiel setzen wir zuerst mal ein Gittertor, das sich bei Betätigung eines Schalters nach oben bewegt und den Eingang freigibt und bei erneuter Betätigung den Eingang wieder verschliesst.

Wer das nachvollziehen will, benötigt Kenntnisse, wie man im Spacer z.B Vobs in die Welt setzt. → Vobs erzeugen.
Wie man diese Objekte im Spacer bewegt, zum platzieren, kann man hier erlernen → vobs_bewegen_und_rotieren

• Ein Gittertor als Mover ergibt natürlich nur Sinn, wenn das Tor/Mover auch Kollision gegenüber Pc/Npc hat. Sonst laufen die einfach durch das Gitter durch
  • Kollision: Besitzt ein Mover nur, wenn man selbige auch einschaltet. (dazu später mehr)
  • Logischerweise ist es so, dass nicht nur der Npc, nicht durch einen Mover mit aktivierter Kollision laufen kann, sondern der Mover kann sich dann auch nicht durch einen Npc bewegen.
  • Beispiel: Wenn wir eine Stachelfalle bauen, die auslösen würde, wenn der Player darüber läuft und die Stacheln (das ist in diesem Falle der Mover), hätten eingeschaltete Kollision, dann würden sie einfach den Hero anheben, der dann auf den ausgefahrenen Stacheln stehen würde.
  • Ich habe mal das Gitter unseres Mustermovers durch einen Klick auf das Gitter aktiviert. Sofort zeigt sich ein „„roter Linienquader, den der Fachmann „BoundingBox“ nennt. Genau diese BoundingBox gibt das Mass des Kollisionsbereichs eines Movers an.

• Leider ist diese Boundingbox keine feste Grösse, sondern verändert sich noch beträchtlich, wenn wir den Mover nicht als „Auf-Ab-Tor“ benutzen würden, sondern als „Drehtor“

• Der Mover würde schon jetzt klemmen und sich niemals bewegen, wenn es da nicht eine Besonderheit gäbe….

• …. alle Wände, Decken, Böden… kurz gesagt, alles was zur Welt gehört, die im 3DS Prog gebaut wurde, hat zwar Kollision gegenüber Npc´s, aber niemals gegenüber einem im Spacer gesetzten Mover der eingeschaltete Kollision hat. Nur aus diesem Grunde ist es uns möglich, später das Gittertor nach oben durch die Decke zu bewegen.

• Aber alles was wir im Spacer gesetzt haben, Vobs, Mobs, etc und den Objekten Kollision eingeschaltet haben, blockiert sofort den Mover an der Stelle, wo sich die Boundingboxen von Mover und SpacerVob/Mob bei der Bewegung des Movers berühren, oder wenn das im Ruhezustand des Movers schon der Fall sein sollte, dass die Boundingboxen kollidieren, dann läuft der Mover erst gar nicht an.

• Ich beschreibe das deshalb so präzise, damit ihr später, wenn ihr eure eigenen Mover in die Welt setzt, diese Dinge beachtet und euch nicht wundert, dass euer Mover, einfach keinen „Mucks“ macht, weil diese Zusammenhänge von Mover und Kollision euch nicht bekannt sind.

• Wir starten den Spacer und öffnen die zu bearbeitende *.ZEN
  • Wir nehmen uns das ObjektPagesFenster vor, setzen einen Haken bei „Hold“ und stellen jetzt die Zeit auf etwa 12:00. Jetzt wird es, egal wie lange wir arbeiten, nicht regnen im Spacer und auch nicht dunkel werden. 12:00 habe ich gewählt, weil es da eigentlich am hellsten sein müsste.

• 3.1 Der Mover wurde im Objektfenster des Spacers leider ein wenig versteckt.
  • Ihr klickt euch durch den Pfad → zCVob → zCTriggerBase(abstract) → zCTrigger → zCMover

• 3.2 Jetzt klicken wir mit der rechten Maustaste auf eine freie Stelle im Spacer Hauptfenster. Wenn ihr dabei ein Objekt erwischen/aktivieren würdet, wäre euer Mover ein „Child of Irgendwas“ und das wollen wir nicht.
• 3.3 Es öffnet sich das kleine Vobfenster mit der Option „Insert Mover“

• 3.4 Wir klicken mit der linken Maustaste auf die Option „Insert Mover“ und erhalten das Moverfenster. Das Einsetzen eines Movers erfordert einen eindeutigen Namen für das Objekt. Wir nennen ihn mal „TESTMOVER“ und schreiben den Namen mit GROSSBUCHSTABEN in das Fenster….

• und drücken anschliessend auf „OK“ und erhalten ein graues Würfelchen und ein Koordinatenkreuz mit der von uns angegebenen Bezeichnung „TESTMOVER“.

• 3.5 Wir wenden uns wieder dem Objektfenster zu, da ja unser Mover jetzt ein Visual (*.3DS) benötigt. Das Objektfenster stellt sich folgendermassen dar…

• 3.6 Als Visual wählen wir „OC_GATE KITCHEN.3DS“. Das passt deshalb so genau, da das Mass des Durchganges im 3DS Prog beim Bau der WIKI-Testwelt darauf abgestimmt wurde. Auch solche Dinge solltet ihr beim modden in der Vorplanung beachten.
• Wir tragen das von uns gewählte Mesh (*.3DS) ganz unten im Filefenster des Objektfensters ein….

• und klicken anschliessend auf den Button „Apply“ und unser Gitter erscheint anstatt des grauen Würfelchens.

Nicht vergessen ab und an mal eure *.Zen abzuspeichern (strg/s)

• 4.1 Wir verschieben das Movergitter in den Durchgang, achten darauf, dass es nicht verkippt ist, am Boden unten abschliesst und mittig eingesetzt ist.

• 5.1 Ein Keyframe ist die Position die ein Mover einnehmen kann. Für eine Geradeausfahrt benötigt man üblicherweise lediglich 2 Keyframes, es sei denn, dass die Fahrt des Movers auf seiner Wegstrecke vom Start zum Ziel unterbrochen werden soll. Das bedarf aber besonderer Steuerelemente. Da wir unser Gitter nur nach oben fahren aus der Startposition (geschlossen) zur Endposition (geöffnet) benötigen wir ebenfalls nur zwei Keyframes.
  • 5.2 Keyframe 0 Startposition
  • Wenn wir unseren Mover sauber in den Durchgang eingebaut haben und der Durchgang durch das Gitter geschlossen ist, befindet sich unser Mover bereits in Startposition, also auf der Position des Keyframes 0. Allerdings müssen wir das dem Mover noch „sagen“, dass er sich auf der Keyframe 0 Position befindet und gehen folgendermassen vor:
  • Wir klicken mit der linken Maustaste auf das Movergitter, das daraufhin seine Boundingbox zeigt.
  • Dann wenden wir uns dem ObjektPagesFenster zu, das folgendermassen aussehen sollte:

• Angezeigt wird der Keyframe 0,
• Grau unterlegt sagt uns, dass der Keyframe 0 noch nicht programmiert ist,
• Der Punkt ist gesetzt auf „Insert“ == richtig
• Wir klicken zum programmieren des Keyframes 0 auf den Button „new key“
• Die grau unterlegte 0 der Keyframeanzeige färbt sich schwarz
• Damit ist Keyframe 0 programmiert

• Wir aktivieren den Movemodus indem wir bei aktiviertem Movergitter (BoundingBox ist sichtbar) die Taste „M“ drücken, oder direkt in der senkrechten Buttonleiste den Button „M“ anklicken.

• 5.3 Keyframe 1 (Endposition)
• Danach bewegen wir das Movergitter mit der Taste „A“ senkrecht nach oben in die gewünschte Position

• Oben angekommen klicken wir auf den Button „new Key“
• Die schwarze 0 wechselt zu einer schwarzen 1.

• Damit ist Keyframe 1 programmiert.

• Wir klicken im Objektfenster auf den Button „Apply“, woraufhin unser Movergitter nach unten in die Ausgangsposition schnappt und speichern zwischendurch auch mal wieder unsere *.Zen ab (strg/s)

• 6.1 Was immer wieder Verwirrung schafft, ist, dass wenn wir, wie im Punkt oben beschrieben den Button „Apply“ geklickt haben, der Mover zwar in die Ausgangsposition zurückspringt, nun steht er ja wieder auf Keyframe 0, das aber im ObjektPagesfenster nicht angezeigt wird. Dort wird immer noch Keyframe 1 signalisiert.
• 6.2 Wir können das ändern, wenn wir auf den linken der beiden Pfeilbuttons klicken - dann zeigt sich sofort die 0 zwischen den beiden Pfeilbuttons, ohne dass sich der Mover (Stellung Gitter geschlossen) bewegt.
• 6.3 Der darf sich dabei auch nicht bewegen, da das Gitter ja geschlossen ist und geschlossen ist Keyframe 0
• 6.4 Wenn ihr zwischen den Pfeiltasten hin ← → her klickt schnappt das Movergatter auf und zu.
  • Pfeiltasten

• 6.5 RESET
• Wenn ihr genug mit den Pfeiltasten gespielt habt :o) dann bitte die Keyframe-Anzeige im ObjektPagesFenster wieder auf Keyframe 0 stellen und den Butten „Apply“ im Objekt-Fenster drücken (reset aller Testaktionen) So lange ihr bei den Frame Positionen nichts neugespeichert habt, erhaltet ihr immer wieder eure in 5.1 - 5.3 programmierte Grundeinstellung. Das ist auch praktisch, wenn ihr mal aus Versehen eine falsche Positionierungstaste (Tastatur) betätigt und das Movergatter verdreht oder verschiebt. Einfach resetten mit dem „Apply“ Button des Objektfensters und alles ist wieder in bester Ordnung.
• 6.6 TESTFAHRT
  • Wir klicken im ObjektPagesFenster im linken Teilefenster auf den Eintrag „TRIGGER“

• Danach auf den Button „Send“ …..

• und jetzt sollte unser Gitter sich nach oben bewegen. Was auffällt: So lange der Mover in Bewegung ist, färbt sich seine BoundingBox „ORANGE“ und wechselt erst wieder zu „ROT“, wenn die Endposition „OBEN“ oder „UNTEN“ erreicht ist.

• Das könnt ihr mehrere Male machen und wenn eure Freude und der Spieltrieb nachgelassen haben, dann bitte den Mover wieder, wie unter 6.5 beschrieben resetten.

• 7.1 Betrachten wir doch mal wieder unser Objektfenster bei angewählem Movergatter ….erschreckend!!! Es wimmelt nur so von Einträgen und Einstellmöglichkeiten, von denen wir nicht mal 10% für unseren Mover benötingen - also… keine Bange! ich habe mal alles mit einem Punkt versehen, was für unseren Mover relevant ist:

• GRÜN =..Einstellungen die wir schon vorgenommen haben im Verlaufe dieses WIKI, oder aber Standard-Einstellungen die zu unserem Mover passen und nicht verändert werden müssen

• ROT =…Einstellungen die wir noch vornehmen müssen

• BLAU =..Einstellungen, die wir eventuell vornehmen

• VobName:NAME_UNSERES_MOVERS

• visual:Name unserer *.3ds (Mesh des Movers)

• showVisual:TRUE (wir wollen den Mover sehen)

• cdStatic:FALSE

• cdDyn:TRUE (unserem Mover Kollision geben)

• staticVob:FALSE

• triggerTarget:NAME_OBJEKT_WAS_GETRIGGERT_WERDEN_SOLL (hier könnten wir als Adresse unseren eigenen Mover selbst eingeben, wenn wir wollten, dass nach dem Öffnungsvorgang das Movergitter wieder automatisch zuläuft)

• MOVER(Ordner)
  • moverBehavior:2STATE_TOGGLE (Diese Einstellung ist für einen Mover richtig, der nichts anderes tun soll, als sich von A → B bewegen und beim nächsten Aufruf wieder von B → A) - Möglich wäre zum Bsp. LOOPING, was aber keinen Sinn ergäbe das Tor im Dauerbetrieb pausenlos auf und zu laufen zu lassen. Andere Einstellungen benötigt man z.B. wenn bestimmte Steuergeräte eingesetzt werden, was aber hier im Mover Grundlagen Wiki zu weit führen würde.

• KEYFRAME(Ordner)
  • moveSpeed: Die Grundeinstellung ist entweder immer zu langsam oder immer zu schnell.
    • Woher soll die Engine wissen, wie schnell oder langsam wir unser Tor laufen lassen wollen?
    • Wert > Mover bewegt sich schneller
    • Wert < Mover bewegt sich langsamer

• Besonderheiten und Macken: Manchmal (selten) ist der Eintrag einfach nicht da um den Speed einzustellen. Was tun?
• *.Zen abspeichern, Spacer verlassen und neustarten. Dann ist der Speedeintrag wieder da! Toll???

• posLerpType:LINEAR (unser Mover läuft bolzgrade nach oben, der braucht keine Kurve)
  • mögliche Einstellungen:
    • CURVE (vorgegebene Standard-Einstellung)
    • LINEAR
    • Wenn ihr zum Beispiel 6 Keyframes im Kreis gesetzt hättet, würde der Mover sich mit der Einstellung „LINEAR“ auf der Linie eines Sechseckes bewegen und wenn ihr die Einstellung „CURVE“ gewählt hättet, würde er sich entlang einer sauberen Kreislinie bewegen.

• speedType:SLOW_START_END (Für ein schweres Eisentor genau richtig. Der Mover läuft langsam an - beschleunigt - und wird gegen Ende der Fahrt wieder langsamer

• SOUND(Ordner) (FAHRGERÄUSCHE)
  • sfxOpenStart:GATE_START (metallisches Startgeräusch)
  • sfxOpenEnd:GATE_STOP (metallisches Ankunftsgeräusch)
  • sfxMoving:GATE_LOOP (metallisches-Laufgeräusch während der Fahrt)
  • sfxCloseStart:GATE_START (metallisches Startgeräusch)
  • sfxCloseEnd:GATE_STOP (metallisches Ankunftsgeräusch)
  • Wenn ihr ein Steintor hättet… Stone_START, STONE_STOP… etc…

• 8.1 Jetzt benötigen wir noch ein Steuerelement um unseren Mover anszusteuern, das heisst, die Fahrt auszulösen. Wir benützen dazu zuerst einmal einen Switch.

• Wer noch nie einen Switch, das ist ein oCMob, genauer gesagt ein oCMobSwitch im Spacer gesetzt hat, der sollte sich jetzt zuerst mal folgendes Wiki durchlesen und dessen Inhalt auch verinnerlichen → oCMobSwitch

• 8.2 Wir platzieren den Switch (LEVER_1_OC.MDS)

• Jetzt benötigen wir einen Eintrag im Objektfenster unter
  • MOB(Ordner)
    • triggerTarget:TESTMOVER (Das ist der name unseres Movers)

• wir klicken im Objektfenster des Switches oben rechts auf den Button „Apply“
• wir klicken einmal in das Spacerhauptfenster
• noch einmal auf unseren Switch
• und jetzt sollte sich eine „blaue Linie“ zeigen, die vom Switch zum Mover führt
• das ist unsere Kontrollanzeige, ob der Switch mit dem Mover richtig verlinkt ist

• nicht vergessen den Switch auf rewind:TRUE zu setzen. Ansonsten habt ihr nach dem Schalten mit dem Switch immer eine Leerfahrt, bis der Mover wieder reagiert

• wir lassen den Switch angewählt und wenden uns dem ObjektListFenster zu
• Dort ist jetzt nicht mehr der Mover eingetragen, sondern der Switch.
• ansonsten verfahren wir wie unter 6.6 in diesem Wiki (TESTFAHRT) und der Mover sollte sich nach oben bewegen.

• Die orangefarbene Boundingbox die den Mover bei Bewegung umgibt, sehen wir jetzt nicht, da ja der Mover nicht angewählt ist, sondern der Switch.

• 8.3 Triggertarget des Movers. Auch ein Mover hat, genau so wie der Switch ein Triggertarget.
  • Reihenfolge: Wenn der Mover angesteuert wird, führt er zunächst mal seinen Befehl aus, seine Keyframes abzuarbeiten. Erst wenn er beim letzen Keyframe angekommen ist (Endposition), führt er anschliessend noch den Befehl aus, der im Triggertarget eingetragen ist. Das können wir uns zum Beispiel folgendermassen zu nutze machen:
  • Wir triggern den Mover auf sich selbst. Damit erreichen wir, dass wenn der Mover seine Endposition erreicht hat, also das Gatter hochgefahren ist, selbiges wieder automatisch nach unten fährt und dann wieder in der geschlossenen Stellung verbleibt.
  • Allerdings muss die Movergeschwindigkeit so langsam sein, dass der Hero auch durchlaufen kann, bevor das Gitter wieder nach unten fährt.
  • Warum sollten wir so etwas tun? Vielleicht wollen wir, dass der Hero einen Flur entlang geht und eben momentan nicht zurückgehen kann (Gameplaysteuerung)?
  • Vielleicht sind Feinde in dem Raum und er soll nicht fliehen können, sondern gezwungen sein den Kampf aufzunehmen?
  • Was auch immer, es ist eine zusätzliche Steuermöglichkeit.

• 8.4 Scriptseitige Steuerung: Über den Switch, der ja auch die Optionen:
  • ConditionFunc:
  • onStatFunc:
  • besitzt kann man ebenfalls den Mover aufrufen unter irgend welchen Bedingungen.

• 8.5 TriggerBox: Über einen oCTriggerscript kann man natürlich ebenfalls den Mover aufrufen.

2016/02/17(dlz)