Hilfe! Weiterleitung mit Cast to.... schlägt fehl

Zitat von Hans_Ulrich

Ok die Videos werde ich mir definitiv mal anschauen. Aber so ganz falsch habe ich doch das Cast to.. nicht verwendet oder? Selbst im Buch "Spiele entwickeln mit Unreal Engine 4" von Jonas Richartz wird beschrieben, dass das Cast to für "eine direkte Kommunikation zwischen zwei Blueprints" verwendet wird. Nur leider zeigt er nicht wie das zwischen 2 Objekten/Actors/Blueprints genacht wird.

Ich werde mich jetzt erstmal, dank euren zahlreichen Hilfen, versuchen da durchzukämpfen und es zu verstehen. Ich werde außerdem versuchen was auf die Beine zu stellen.

Wenn es recht ist würde ich im richtigen Projekt dann wieder hier rein schreiben, sobald ich mit diesem Thema wieder Hilfe benötige. Verstanden habe ich das irgendwie noch gar nicht leider

Vielen Dank für eure Hilfe bisher!!! Habe ein paar likes da gelassen

Alles anzeigen

Dann ist dieser Satz falsch, sorry. (Wahrscheinlich eher schlecht ausgedrückt oder du hast es falsch verstanden. Der Autor ist hier im Forum und hat schon Ahnung würde ich behaupten)
Unter casting versteht man in der Programmierung die Typenumwandlung.

Es gibt auch noch die Doku

https://docs.unrealengine.com/…rints/UserGuide/CastNodes

Das Cast to Blueprint ist leider ne komische Sache. Auhc ich habe damit noch große Probleme, bin allerdings schon länger dabei. Das wird schon

Cast to ist ziemlich simpel wenn man es verstanden hat.

Ich versuch es mal an einem kleinen Beispiel zu erklären:
[Blockierte Grafik: https://dbs.cs.uni-duesseldorf.de/lehre/docs/java/javabuch/html/images/VererbTransp.gif]

Hier haben wir ne simple Vererbungshierarchie.
Zur kurzen Erläuterung:

Strassenfahrzeug erbt von Transportmittel.
Auto erbt von Strassenfahrzeug.

Das bedeutet ein Auto ist auch ein Transportmittel.
Allerdings muss nicht jedes Transportmittel ein Auto sein.

Angenommen ich habe ein Auto Objekt und speichere das in einer "Transportmittel" Variable, dann ist dies ein Upcast.
Da ein Auto IMMER ein Transportmittel ist, ist hier eine "Castto" Node nicht notwendig.

Nun kommen wir zum Gegenteil. Ich möchte mein Straßenfahrzeug wieder zu einem Auto machen. Nun haben wir ein Problem. Ein Transportmittel könnte theoretisch auch ein Lastwagen oder ein Güterzug sein. Hier ist nun die CastTo Node notwendig um zurück zu einem Auto zu kommen. Der Cast wird fehlschlagen wenn man zb ein Lastwagen, der in einer Transportmittel Variable gespeichert ist, versucht zu einem Auto zu casten. (Macht wiederum Sinn, da ein Lastwagen kein Auto ist)

Cast to kann also NUR verwendet werden solange sich ein Objekt in der selben Vererbungshierarchie befindet.
Oben wären das zb:
- Fahrrad > Zweirad > Strassenfahrzeug > Transportmittel

Um auf das jetzige Beispiel zurück zu kommen.

Lampe und Character befinden sich nicht in der selben Vererbungshierarchie. (Es sei denn du machst ein Spiel in dem du eine Lampe spielst)
von Character zu einer Lampe zu casten ist also komplett falsch.

Hoffe es wird damit etwas klarer.

@Veelos Super post. Grafisch versteht man sowas gut, aber ich hab auf die schnelle nichts gefunden.

Zitat von Hans_Ulrich

Ich wollte diesem Mann auf keinen Fall unterstellen, dass er keine Ahnung hat! Ich verschlinge sein Buch seit Wochen mit Leidenschaft und bin durch ihn erst auf dieses Forum gestoßen Nur habe ich diesen Satz richtig zitiert. Wahrscheinlich deute ich ihn einfach falsch. Dass das Casting zur Typenumwandlung benutzt wird, werde ich mir merken.

Mein Zusatz war auch eher so gemeint, dass ich ihm nichts unterstellen will noch dir.

Interessanterweise haben viele auch ohne das Buch die selbe Deutung vom Cast, wie du. Es ist auch naheliegend zu diesem Schluss zu kommen, wenn man dieses Programmierkonzept nicht kennt.
Der Satz ist wahrscheinlich auch nicht falsch im richtigen Kontext, da der Cast ein Werkzeug ist den du ja bei der Kommunikation zwischen zwei Objekten benötigst, weil z.B. ein Event (Collision, Trace Hit, Damage, etc) ja oft mit einer sehr allgemeinen Referenz zu einem anderen Objekt ankommt (Typ Object oder Actor) und man muss dann erst in einen spezifischeren Typ casten, damit man auf die nötigen Funktionen/Events/Variablen zugreifen kann.

Zitat von Hans_Ulrich

Mit den Parents und Childs habe ich es soweit verstanden, aber mal ne andere Frage. Nehemn wir mal an ihr würdet mit eurem Spieler über eine Waffe laufen und die Waffe soll mit einem Tastendruck despawnen (also zerstört werden), dann muss doch irgendwie eine Kommunikation zwischen Spieler und Waffe stattfinden. nur wie wird das Signal zur Waffe geleitet

Du kannst bei der Waffe zb eine Trigger Box hinzufügen und dann im Actor mit dem "OnCollisionEnter" Event arbeiten. (Finde gerade kein Guide dazu aber wenn du bisl

Zitat von Hans_Ulrich

Also soweit ich das bisher mit Interfaces verstanden habe, sind Interfaces GROB GESAGT nicht anderes als CustomEvents. Nur mit dem Unterschied, dass darauf mehrere Blueprints zugreifen können. Also ne Kombination aus Cast to.. und CustomEvent irgendwie

Uhm nein.
1. Hört auf damit "Cast to" als "Kommunikation zwischen BPs" zu sehen. Das ist schlicht und einfach falsch. Mit Cast To sage ich einem Objekt "Transportmittel" das es eigentlich auch vom Typ "Auto" ist. Damit kann man dann auf Funktionen vom Typ Auto zugreifen. (zb Hupen) was ein Transportmittel nicht kann.
Aber wir reden hier trotzdem immer noch vom selben Objekt. Mit Cast to kann man nicht mit einem anderen Objekt kommunizieren.

Das was ihr wahrscheinlich missinterpretiert ist, wenn ihr bereits eine Referenz habt und diese Castet. Trotzdem braucht ihr dazu eine Referenz. Sonst weiss CastTo nicht welches Objekt es casten soll. Beispiel:

GetPawn gibt euch eine Referenz zurück. Die Referenz ist aber gleichzeitig auch eine Referenz auf euren Character. (Sofern ihr einen character steuert). Nur weiss der Pawn das noch nicht und ihr könnt deswegen nicht auf die Funktionen von eurem Character zugreifen. Um das zu können müsst ihr die Pawn Referenz erstmal zu character casten. Trotzdem bleibt es die selbe Referenz.

2. Fasst Interfaces erst dann an wenn Ihr Polymorphie verstanden habt. Ich habe dieses Thema schon Leuten im Voice Chat Stundenlange erklärt. Leider nur mit wenig Erfolg. Das in einem Post zu erklären wäre schon etwas zu viel des Guten.

3. Programmieren lernt man nicht über Nacht. Es mag vielleicht etwas einfacher aussehen als bei Artisten aber lasst euch davon nicht täuschen. Auch Programmieren braucht Jahrelange Übung bevor man darin richtig gut ist. (Und nein, ich sehe mich selber nicht als "richtig gut" an^^). Trotzdem kann man durch rumprobieren in der Unreal Engine schon vieles hin bekommen ohne großartig Coden zu können.
Du greifst hier schon Themen vor die Fortgeschrittener sind, obwohl du bei den Basics noch wacklig stehst.
Deshalb, wenn du es wirklich lernen willst, dann nimm dir die Zeit.

Zitat von Veelos

3. Programmieren lernt man nicht über Nacht. Es mag vielleicht etwas einfacher aussehen als bei Artisten aber lasst euch davon nicht täuschen. Auch Programmieren braucht Jahrelange Übung bevor man darin richtig gut ist. (Und nein, ich sehe mich selber nicht als "richtig gut" an^^). Trotzdem kann man durch rumprobieren in der Unreal Engine schon vieles hin bekommen ohne großartig Coden zu können.
Du greifst hier schon Themen vor die Fortgeschrittener sind, obwohl du bei den Basics noch wacklig stehst.
Deshalb, wenn du es wirklich lernen willst, dann nimm dir die Zeit.

Kleiner Zusatz zu diesem Punkt. Es ist mMn falsch zu sagen, dass Blueprints keine Programmierkenntnisse benötigen.
Sie reduzieren eher nur die Schwelle für den Einstieg, dennoch wendet man auch mit Blueprint Objekt-Orientierte-Programmierung (und auch Komponentenbasierte Programmierung) an und muss die Konzepte verstehen.
Das ist finde ich ein riesiger Fehler im Marketing von UE4.

Daher lege ich jedem ans Herz mindestens ein/zwei Monate lang sich mit reinem C++ zu beschäftigen , um die Konzepte kennenzulernen und zu verstehen, bevor man mit dem Biest arbeitet was UE4 ist. Das ermöglicht die ganze Sache in einer Umgebung zu verstehen, die nicht so komplex ist wie die Unreal Engine. Wenn du all diese Konzepte verstehst, dann kommst du viel schneller auf viel elegantere Lösungen für deine Probleme. Es wird BTW auch immer gesagt dass C++ schwer ist, dies ist jedoch eher eine Aussage die eher in den 90gern gültig war und auch eher für größere Projekte galt, da man einfach in C++ sehr sauber arbeiten musste, dafür viel Kontrolle über den Speicher hat.
Das mag etwas trocken sein, aber auch Spieleprogrammierung ist kein Spiel, sondern wirkliche Programmierung.