Solaiel Klar, ist die ganz einfache Lösung.
Problem hier ist halt nur, dass sich das Event bei Mapwechsel resetten würde, quasi wenn du 500 frames gewartet hättest dann aber die Map verlässt und neu betrittst, erneut 600 frames gewartet werden.
Jeder so wie er zufrieden ist/ es mag 
Danke fürs teilen!
Ich glaube das, was du erreichen willst, wird eher mit einem CanvasLayer gelöst.
CanvasLayer bewirkt, dass dessen Children statisch am Bildschirm und nicht auf der Karte "kleben".
Die Kamera machst du dann einfach als children des KinematicBodies des Spielers und setzt einen Haken bei "current".
Aber grundsätzlich zu deiner Frage: Ja, das würde auch gehen, ist aber in dem Fall unnötig kompliziert.
Mein erstes Godot-Projekt
Bestimmt haben manche von euch schonmal den Godot-Editor gestartet, ohne bösen Hintergedanken ein neues Projekt erstellt und dies zum bearbeiten geöffnet... Doch dann kommt die Frage: Was mache ich jetzt?
Dieser Beitrag soll dazu dienen, diese Frage in eine weniger verzweifelte Lage zu rücken.
Godot Engine arbeitet mit sogenannten "Szenen": Die meisten werden vermutlich denken, dass Szenen quasi nur als verschiedene Karten gebraucht werden, auf denen sich der Spieler bewegt, wie es zum Beispiel beim RPG Maker der Fall ist, aber dem ist nicht so. Der Spieler kann zum Beispiel selber eine Szene sein, welche dann auf einer anderen Szene instanziiert oder einfacher, platziert wird.
Bei Kartenwechsel würde man also eher überlegen den alten Spieler zu löschen und auf der neuen Szene einfach einen neuen Spieler zu platzieren, als man im spielerischen Sinne wohl denkt, dass der Spieler teleportiert wird.
Oder man hat einen Gegner, welcher andere Gegner auf der Karte spawnt, hier würde man die Szene des neuen Gegners einfach in die momentane Szene instanziieren, quasi Duplikate erschaffen.
Gucken wir uns doch zunächst einmal die oberste Leiste an. Hier kann man wählen zwischen
2D: Zeigt die 2D Ansicht der momentanen Szene an (2D-Spiele sind für Einsteiger empfehlenswert).
3D: Zeigt die 3D Ansicht der momentanen Szene an.
Script: Zeigt den Script-Editor an.
AssetLib: Öffnet einen Libary Store, in dem man sich kostenlos Ressourcen oder vorgefertigte Demo-Projekte herunterladen kann.
Weiter rechts findet man dann
Pfeil: Startet das Projekt mit der ausgewählten "Anfangsszene".
Stopp: Pausiert die Anwendung des Projektes (Spiel muss gestartet sein).
Abbrechen: Stoppt die Anwendung des Projektes (Spiel muss gestartet sein).
Filmklappe mit Pfeil: Startet das Projekt mit der momentan geöffneten Szene.
Filmklappe mit Ordner: Tool um Szenen schnell zu starten, wird aber meistens nicht gebraucht...
Wenn wir nun aber versuchen durch Drücken auf den Pfeil unser Spiel zu starten, erhalten wir folgende Meldung:
Abbruch, die Engine ist verbuggt... schnell noch zu Unity wechseln...
Nein 
Godot möchte uns nur höflich darauf hinweisen, dass er gar nicht weiß, mit welcher Anfangszene er das Projekt nun starten soll. Und wir wollen ja nicht, dass der Computer entscheidet womit unser vollkommenes Spiel beginnt... Versuchen wir uns also eine Test-Szene zu erstellen, welche dann standardmäßig jedesmal gestartet wird, wenn wir auf diesen lustigen Pfeil klicken:
Deshalb müssen wir erst einmal eine Szene abspeichern, bevor wir diese dann als "Anfangszene" festlegen können. Wenn wir dies nun aber versuchen, kommt folgende nette Meldung:
Hmmm... Eine Wurzel... Und damit herzlich Willkommen zu meinem Kräuterkundeunterricht!
Doch womit uns Godot eigentlich konfrontieren möchte, sind sogenannte "Knoten", oder wie sie unser englischer Freund nennen würde: "Nodes"!
Nodes bilden quasi unseren Werkzeugkasten für jede gelungene Szene: Es gibt für fast jede Funktion ein dafür angefertigtes Node!
So wie der Automechaniker also zum Schraubenschlüssel greifen würde um eine Schrauber festzuziehen, greift der Informatiker zu einem Sprite-Node, wenn er eine Grafik anzeigen lassen will.
Praktischerweise sind diese Nodes auch noch in Farben unterteilt um grob eingliedern zu können, in welchem Bereich man sich gerade befindet:
Blau: Node2D. Alle Nodes welche zu dieser Gruppe angehören sind dafür bestimmt im 2D-Umfeld verwendet zu werden und zeichnen meistens auch etwas auf den Bildschirm (Bsp.: Sprite-Node)
Sie haben eine Position und sind somit in der Szene verschiebbar
Rot: Spatial. s. Blau nur für 3D
Grün: Control. Wie der Name schon sagt sind alle Nodes dieser Gruppe für Steuerung zuständig
Tiefer ins Detail will ich da auch nicht gehen... Ich empfehle einfach sich im Internet über die einzelnen Nodes explizit zu informieren. Denn man weiß nur was man machen kann, wenn man weiß was man hat 
Erstellen wir also einfach ein Node. Ein graues Node ohne jegliche Funktionen als einfach nur da zu sein. Es hat keine Position, ist somit unbewegbar, und dient quasi nur als "Vater" welcher dann irgendwann über seine kleinen "Kinder"-Nodes wacht. Dieses Node können wir nun mit einem Doppelklick darauf umbenennen. Es empfiehlt sich einen Namen zu wählen welcher die Szene gut zusammenfasst, in unserem Fall wäre "game" sicher ganz passend...
Wenn wir das nun also endlich hinter uns haben, können wir nun die Szene abspeichern (Über effektive Dateistrukturen bei Godot-Projekten komme ich vielleicht wann anders zu sprechen...) und sie beim Drücken auf den Pfeil dann als Hauptszene auswählen. Nun sollte sich ein Fenster öffnen, bei dem nichts anderes als ein grauer Bildschirm zu sehen ist. Keine Fehler... Schön, wird haben etwas erreicht! Unser Spiel ist bugfrei!
Doch was wird nur passieren, wenn wir uns selbst ein kleines Script basteln?... Mir graut es schon...
Scripting
Godot Engine kann man in 2 verschiedenen Varianten downloaden:
- Standard (GDScript, wird von mir immer verwendet)
- Mono Version (C# Support)
Die Mono Version ist glaube ich noch nicht komplett ausgereift, aber viel habe ich mich damit nicht beschäftigt...
Doch wo liegt nun der Unterschied?
GDScript ist eine Programmiersprache, welche extra für Godot entwickelt wurde. Sie ähnelt dabei sehr stark Python.
C# ist eine andere populäre Programmiersprache welche eben bei Leuten welche schon programmieren können gerne verwendet wird.
Ich kann da nicht viel sagen, ich weiß aber das es einen leistungstechnischen Unterschied gibt bei logischen Operationen bei GDScript gegenüber C#.
Wer also eine Schach KI zum Beispiel oder eine Echtzeitsimulation entwickeln will, versucht wohl besser mit der C# Version klar zu kommen. Ansonsten merkt man diesen Unterschied allerdings nicht.
Erstellen wir also unser erstes GDScript-Script-Script..Scr... GDScript-Script!
Dazu klicken wir auf unser "game"-Node und dann auf die Schriftrolle mit dem grünen Plus oben rechts. Nun öffnet sich ein Optionsfenster, welches wir allerdings unberührt lassen können.
Wir müssen aber bei "Pfad" unser Script irgendwo abspeichern, es empfielt sich dieses Script irgendwo in der Nähe der Szene abzuspeichern, damit irgendwann kein Tohuwabohu entsteht...
('#' Sind in GDScript Kommentare)
extends Node: Dieses Script erbt von diesem Node-Typ. Eigenschaften, Funktionen... Wird immer benötigt um auf die Funktionen der spezifischen Nodes zuzugreifen. (Heißt dann aber je nach Node anders!)
func _ready(): Funktion welche jedes Node besitzt: Sie wird aufgerufen wann immer das Node in der Szene instanziiert ist und quasi "betriebsbereit" ist.
func _process(delta): Funktion welche jede Frame aufgerufen wird. Delta wird verwendet um eine Zeitkonstante zu haben und beinhaltet die Zeit, welche seit dem letzten Frame vergangen ist.
pass: Eine Funktion muss Befehle beinhalten. Dieses Statement dient jediglich dazu einfach nichts zu tun, umgeht aber den Syntax-Fehler, welcher ohne dieses Statement entstehen würde.
Dieses Script macht nun genau soviel wie unser Spiel: Nichts.
Wenn wir aber unser berühmtes "Hallo Welt"-Script erstellen wollen, säe das wie folgt aus:
print: Schreibt etwas auf die Konsole (In dem Fall: "Hallo Welt!")
Nun können wir unten auf unserer Konsole eben diesen Hilfeschrei unseres Programmes begutachten und uns laut auf die Schulter klopfen: Wir haben es geschafft. Es tut!
Nachdem unser erstes Godot Projekt diesen Meilenstein überwunden hat, frage ich mich wo es unser unschuldiges Projekt wohl als nächstes hinziehen wird...
Ich hab nur nochmal damit es keine Komplikationen gibt ein Bild hochgeladen ^^:
Herzlich Willkommen im Forum 
Zu dem Problem wendest du dich am besten direkt an den VD 2 Remake Thread, da sollte dir am besten geholfen werden können.
Vampires Dawn 2 Remake - Everlasting Blood (Version 1.9!)
Bitte beachte: Man kann dir am besten helfen wenn du dein Problem so gut wie möglich beschreibst:
Was hast du vor dem Absturz gemacht?
Was ist der Absturzfehler? (Detailliertere Beschreibung durch Drücken von F8 bei der Absturzmeldung)
Andere Informationen die zur Behebung des Problems hilfreich sein könnten
Ansonsten wünsche ich dir hier viel Spaß!
Ich habe weiter an meinem Schach-Spiel gearbeitet. Man kann nun:
1) Speichern und Laden
2) Jeden davor gezogenen Zug zurücknehmen
Zudem ist jede Regel die in Schach existiert bereits eingebaut, wodurch ich "nur noch" eine KI und einen Online-Modus einbauen muss.
Die KI geht einfach nach Prioritäten:
1) Spieler rausschlagen
Da es dem Gegner am meisten bringt, wenn er den Spieler schlägt, überprüft er ob er den Spieler schlagen kann.
2) Essen einsammeln
Da es das Ziel ist für den Gegner Essen einzusammeln, guckt er ob er das tun kann.
3) Essen einsammeln vorbereiten
Wenn der Gegner weder den Spieler noch Essen einsammeln kann, bereitet er das Essen einsammeln vor, indem er auf ein Feld zieht, bei dem er als nächstes Essen einsammeln kann
4) Zufälliger Zug
Wenn alles nicht funktioniert, macht er einen zufälligen Zug
Bedingung aller Züge: Gegner darf nicht vom Spieler geschlagen werden dürfen, nachdem er gezogen hat!
Da das aber zu einer unbesiegbaren KI geführt hat, musste ich noch eine Fehlerrate einbauen. bei der der Gegner dann ignoriert ob er vom Spieler rausgeschlagen werden kann oder nicht.
Also ist es möglich, dass er einen Fehler macht, das muss aber nicht zwingend der Fall sein.
Sonst kann ich dazu nicht viel sagen. Das Projekt ist sowieso Open Source, aber ich glaube man kann da nicht soviel raus ziehen.
Es ist einfach eine Frage der Ehre, ob man früher damit anfängt oder nicht...
Der MV war leider noch nie der hellste Stern am Himmelszelt, was Leistung betrifft.
Im Grund genommen ist der MV nur ein Browser mit einer sehr veralteten Chromium Version (Auch wenn die ab 1.6.0 wohl mal upgedated wurde).
Ich fürchte, da lässt sich nichts verbessern.
Das trifft sich doch gut, meine Daten wollte ich eh nicht mehr.
Wie bin ich hier her gekommen? Wo bin ich hier?
Ich sehe gerade, dass diese Grafiken im Stil Modern Flat UI nicht sichtbar sind. Ich werde es weiterleiten.
Es würde sich vielleicht nochmal lohnen die Preise zu aktualisieren und zu erwähnen, dass man beim MV die Bildschirmgröße via Plugin verändern kann.
Edit: Ich habe gerade gemerkt, dass die Preise aktuell sind 
Das Spiel wird über den Editor geöffnet nehme ich an? Der Debug Mode funktioniert nämlich logischerweise nur im Playtest.
Und andere Tasten wie Esc, F2, F4, F5, F8 funktionieren?
Irgendwelche Plugins installiert?
Sonst kann es sein, dass du den Editor auf die Version 1.6.1 geupdated hast, dein Projekt aber immernoch auf einer älteren Version ist:
https://forums.rpgmakerweb.com…6-1-stable-release.96715/
ZitatEveryone, please read the instructions carefully. The bugs that are being reported shouldn't happen if the correct files were even copied properly. Such examples like the "CTRL BUG" shouldn't happen if you copied index.html, package.json, the rpg*.js files and so on.
https://forums.rpgmakerweb.com…6-1-stable-release.96715/
Dort siehst du wie du dein derzeitges Projekt auf die Version 1.6.1 updatest, und vergiss bitte nicht ein Backup zu machen!
Heißt sehr langsam, dass du mit niedrigen FPS spielst? FPS Kannst du beim MV mit F2 einsehen
Der Origin Wert ist nicht so wie du ihn dir vorstellst:
Er kann nämlich nur 2 Werte haben, entweder 0 oder 1:
0: Verankerung links oben
1: Verankerung in der Mitte
Auch kannst du nicht von der Größe der Karte ausgehen um den Mittelpunkt zu setzen, ein Bild wird nämlich nicht auf der Map angezeigt sondern statisch auf dem Bildschirm.
Du musst dir also die Bildschirmgröße angucken.
Wenn du also die Standardmäßige Auflösung hast sind die Werte bei dir:
X: 816
Y: 624
Die Hälfte davon wäre:
X: 408
Y: 312
Nun sollte folgender Scriptcall funktionieren:
Mr. Fu Keinesfalls. Die Variablen werden mit var deklariert und sind somit nur für den Scope des Scriptes vorhanden.
Problematisch wird es erst wenn das Script nicht mehr in einen Script-Command reinpasst, wo es sich lohnen würde alles so kurz wie möglich zu halten.
Dies ist hier aber nicht der Fall.
Hintergrund dass ich alles einzeln aufgelistet habe war einfach, dass man beim editieren immer weiß welcher Wert für was steht bei der Bildanzeige.
Commander_Bert Wo ein Wille ist, ist auch ein Weg. Sagen wie könnte ich allerdings auch nicht. Es gibt ja auch keinen Grund sich damit näher zu beschäftigen...
Ja, nur mit dem Script-Schnipsel. Selbst wenn du mehr Bilder anzeigen kannst, ist der Editor so programmiert keine Zahl höher als 100 anzunehmen.
Und den Editor anzupassen wäre eh illegal.
