Hallöchen, falls es jemanden interessiert. Ist mir heute aufgefallen.
Wenn man von einem Blueprint ein Duplicate erschafft und Nodes aus dem ersten in den zweiten kopiert scheint es nicht zu funktionieren. Jedenfalls hat genau so eine Aktion von mir einen Fehler hervortreten lassen. Weiß nicht ob dies für alle Versionen gilt oder auch für die Unreal 5, aber bei mir hats bei der Version 4.27.2 einen Fehler auftreten lassen.
Dachte könnte von Interesse sein. 
Interessant ist es, aber ich weis nicht was für ein Fehler. Und wenn man das BP dupliziert, ich denke mal, du meinst den BP Actor, dann muss ich doch keine Nodes mehr von einem zum anderen kopieren, da die doch alle vorhanden sind.
Haha, ja da habe ich mich wohl schlecht formuliert. 
Also nochmal: Ich hatte einen Parentactor ohne Script. Davon erstellte ich mir einen ChildActor und kopierte Script von einem gänzlich anderen Actor und stellte die Variablen ein. Da ich nicht will, dass in jedem Child des Parent das Script auftaucht, habe ich ein Duplicate des Childactors gemacht. Leider bevor ich das Script im ersten erstellt habe. Deswegen habe ich von dem ersten Child das Script kopiert, in den zweiten Child eingefügt und die Variablenwerte geändert.
Resultat: Hat nicht funktioniert. 
Als ich das Script im zweiten Child gelöscht habe und nun ebenfalls vom gänzlich anderen Actor das Script kopiert und die Variablen gesetzt habe hat alles einwandfrei funktioniert. 
Hoffe war jetzt etwas verständlicher. Keine Ahnung ob es an der Engine oder meinem PC liegt
Schönes Wochenende
Geht es nur mir so, oder kommt mir die Methode ein wenig unorthodox vor?
Warum solle man ein Child von einem Parent erstellen, wenn dieses Child aber etwas gänzlich anderes ist?
Kann natürlich sein, dass ich es absolut falsch lese, aber irgendwie kommt mir das ein wenig falsch vor.
Ich bin mir recht sicher, dass du zu kompliziert denkst. Geht mir ja auch oft so.
Nenn doch einfach mal ein Beispiel, wofür du das genau brauchst. Ich bin mir ziemlich sicher, dass das auch einfacher geht. Zumindest fällt mir noch immer nicht kein Anwendungsfall ein, bei dem so etwas mit Array im Array und Collision etc. nötig wäre.
Aber nur, weil ich das bisher so nicht benötigt habe, heißt das ja noch nichts. Deswegen wäre da ein Beispiel ganz gut.
Bisschen genauer vielleicht. Ansonsten würde ich jetzt einfach nur sagen, benutze die Spawn Actor Node.
Also, mich würde es auch interessieren. Evtl können wir dir andere Optionen nennen, die dir das Leben vereinfachen können.
Um ein Actor nach ihrer Art abzufragen, zb eingestellte Variablen, habe ich die Variablen im Parent bereitgestellt und im Child werden sie unter Construct neu eingestellt. Oder eine super Möglichkeit ist zb das Interface zu nutzen.
Aber man kennt natürlich den Spruch, alle Wege führen nach Rom. Sie müssen halt nur funktionieren. Es wäre aber schade, wenn du nicht alle optionen kennst, um einfacher zu arbeiten.
Ich glaube, du hast das mit der Vererbung usw. ein wenig falsch verstanden.
Normalerweise hast du ein Objekt, sagen wir Auto, also dein Parent/Base. Wenn du jetzt in deinem Spiel neue Autos kreieren willst, erbst du von Auto. Was du bei dem neuen Objekt dann lediglich änderst, ist zum Beispiel PS, Anzahl Sitzplätze, Gänge, Max. Geschwindigkeit, Typ, was auch immer.
Aber du erstellst eigentlich niemals ein Baseobjekt, welches mal eine Wand, mal eine Waffe, mal eine Kuh oder so sein kann.
Wie Fehleranfällig willst du das denn noch machen?
Bleiben wir mal beim Auto. Ich gebe dir mal ein Beispiel in C#, weil damit kann ich noch immer besser umgehen als mit C++. Ich mache es mal nicht als BP, weil dann siehst du vielleicht besser was ich meine.
Das hier wäre jetzt mal eine ganz einfache Basisklasse für ein Fahrzeug. Ich habe sie sehr einfach gehalten. Vorhanden sind halt nur Variablen für PS und MaxSpeed, eine Beispielroutine fürs Beschleunigen, mehr nicht. Die Werte sind leer.
internal class Fahrzeug
{
private int _ps;
private int _maxSpeed;
public int MaxSpeed { get { return _maxSpeed; } set { _maxSpeed = value; } }
public int PS { get { return _ps; } set { _ps = value; } }
public Beschleinigen()
{
int AktSpeed;
// Code zum Beschleunigen
if(AktSpeed >= _maxSpeed)
{
// Nicht weiter beschleunigen
}
}
}Im Code erstellst du so ein neues Fahrzeug.
Fahrzeug Auto = new Fahrzeug();
Auto.PS = 315;
Auto.MaxSpeed = 450;Sprich, du kreierst ein neues Objekt, gibst ihm den Namen "Auto".
Danach stellst du die Eigenschaften des Autos ein, alo PS und MaxSpeed.
Für gewöhnlich hast du dann noch irgendeine Funktion wie Show oder so, damit das Auto dann zu sehen ist. Habe ich jetzt mal weggelassen, weil nicht notwendig für die Erklärung.
Also hast du jetzt ein Objekt Auto mit seinen Eigenschaften, 315 PS und 450 Km/H maximale Geschwindigkeit.
Wie, bzw. wieso, willst du jetzt vom Auto ein neues Auto ableiten? Nimm doch wieder Fahrzeug, dafür ist die Klasse da. Z.B.
Fahrzeug Auto2 = new Fahrzeug();
Auto2.PS = 50;
Auto2.MaxSpeed = 80;Das andere Auto ist fertig, das hat all seine Eigenschaften, warum sollte man davon nun ein zweites Auto ableiten?
Oder noch besser, wieso willst du aus einem Auto plötzlich eine Wand machen, die ja wahrscheinlich ganz andere Eigenschaften hat? Oder eine Waffe, die wiederum andere Eigenschaften hat?
Hey zusammen
Aber du erstellst eigentlich niemals ein Baseobjekt, welches mal eine Wand, mal eine Waffe, mal eine Kuh oder so sein kann.
Da muss ich dir widersprechen. Die Unreal Engine macht nämlich genau das.
Egal was du in der Engine erstellst, du erbst eig. so gut wie immer von UObject.
Alles erbt davon, egal ob du eine Wand, eine Waffe oder eines der über 6000 weiteren Children erstellst.
Es kann also durchaus Sinn machen.
Gruss
Alles anzeigenHey zusammen
Da muss ich dir widersprechen. Die Unreal Engine macht nämlich genau das.
Egal was du in der Engine erstellst, du erbst eig. so gut wie immer von UObject.
Alles erbt davon, egal ob du eine Wand, eine Waffe oder eines der über 6000 weiteren Children erstellst.
Es kann also durchaus Sinn machen.
Gruss
Ja, du erstellst ein Object, welches die Eigenschaften von UObject hat. Du erstellst dann ein neues Base, zum Beispiel Wand, welches die Eigenschaften der UObjectklasse hat plus die Eigenschaften, die deine Wand haben soll. Dann erstellst du von deiner Wandklasse halt eine Wand, aber du erstellst halt keine Wand, die du von dieser erstellten Wand dann erbst.
Ich bin da vielleicht zu wenig ins Detail gegangen. Natürlich kannst du eine neue Basis erstellen, die von einem anderen Objekt erbt. Aber du erbst am Ende immer von einer Basisklasse, nie von einem erstellten Objekt mit all seinen Eigenschaften. Also du leitest niemals von dem Auto 315 PS, Geschwindigkeit 450 das Auto 2 mit 50 PS und Geschwindigkeit 80 ab. Und so klang der Text von Mac halt.
Weil ich mit meinen Build Funktionen nun mal ein Auto und eine Wand erstellen möchte und dazu benötige ich nun einmal zwei verschiedene Childs. Einmal ein Auto Child und einmal ein Wandchild. Die aber beide von dem Parent erben, erstellt werden zu können.
Das Problem das du ansprichst eröffnet sich mir leider nicht. Bei mir funktioniert alles einwandfrei, also warum ändern?
Kannst du ja auch machen. Nur dann solltest du halt eine Basisklasse für dein Auto erstellen und eine weitere für deine Wand, noch eine für die Waffen usw. Ansonsten ist es ja keine Vererbung, ansonsten nutzt du nur die Basisklasse UObject von der Engine. Die hat aber nur die Basismethoden für die Unreal Engine enthalten, keine spezifischen Methoden für dein Objekt.
Tomarr hat auf alle Fälle gut erklärt, wie UE4 das vorgesehen hat. Wie man es im Endeffekt nutzt, ist jedem seins. Da MacArmand das zweckentfremdend, kann später in der UE4 vieles nicht so reibungslos laufen wie es eigentlich sollte. Wie zb das eigentliche Thema vom Thread ist. Es ist zb auch für mich sehr verwirrend, wie MacArmand arbeitet, aber wenn er damit klar kommt, warum nicht 
Nur wird ein anderer Programmierer, falls noch einer hinzukommt, sich daran die Zähne ausbeißen, weil das in der allgemeinen Scriptsprache so nicht vorgesehen ist
Es gibt dafür mehrere Gründe.
Übersichtlichkeit des Projektes
Nachvollziehbarkeit bei Fehlern
Erweiterungsmöglichkeit des Projektes
Allgemeine Fehlervermeidung
Dass es funktioniert, liegt nicht an der Engine oder dem Compiler. Das liegt mehr an der Grundlage, dass man mit C++ in jeder Klasse von jeder Klasse erben kann.
Du kannst es natürlich so beibehalten, nur ich befürchte, dass es bei steigender Projektgröße schwierig sein wird dir bei Fehlern zu helfen. Mal abgesehen davon, dass es unnötig unübersichtlich und entsprechend kompliziert ist, auch was die Übersicht angeht. Und wenn man schon dabei ist programmieren zu lernen, dann sollte man auch gleich mit sauberem Code arbeiten. Ansonsten ist die Verzweiflung früher oder später sicher, wobei entsprechender Frust dann auch zur Aufgabe führen wird.
Ich merke ja schon, dass du für Ratschläge nicht unbedingt zu haben bist. Aber lasse es dir von Menschen sagen, die alle schon einmal ähnliche Wege gegangen sind und entsprechend ähnliche Fehler gemacht haben. Es ist besser, etwas gleich sauber zu lernen, als später frustriert zu sein.
Warum keinen Child eines Child machen.
Wenn die Engine das nicht will und nicht dafür ausgelegt ist, frage ich mich, warum es die Funktion gibt.
Wenn das so problemlos wäre, dann hättest du diesen Thread ja gar nicht eröffnet, oder? 
