Zugriff auf eine Variable in einer Blueprint aus einer anderen Blueprint heraus

Blueprint Communication ist was du suchst.

https://docs.unrealengine.com/…rintCommsUsage/index.html

Ist das Ganze ein HUD-Widget und kann es sein, dass du das Widget zur Laufzeit in dem Hauptwidget erstellst?

Das ist jetzt schwer zu sagen wo der Fehler liegt.

Du kannst in solchen Fällen aber selber mal schauen ob du wirklich die Referenze hast oder nur eine leere Variable vom richtigen Typ.

Ja, ist es. Denn wenn du den Text vor der Erstellung ändern willst geht es nicht, da zur Laufzeit nicht vorhanden, danach ist es schon vorhanden und ausgegeben. Hab letztens auch 2 Tage damit verbracht das zu lösen. Ich editiere das hier gleich mal. Dann mache ich ein paar Screenshots von meiner Lösung und schicke es dir hier. Wollte eigentlich irgendwann ein Tutorial draus machen. Aber das Eine schließt das Andere ja nicht aus.

So, ich hoffe, ich habe jetzt alles in der richtigen Reihenfolge. Wie gesagt, ich möchte ja noch irgendwann ein Tutorial draus machen, das hier ist jetzt halt eine Kurzanleitung. Ich hoffe, ich bekomme es verständlich hin. Natürlich sind die Begrifflichkeiten jetzt meinem Projekt angepasst, du musst da teilweise also etwas umdenken.

Also, du baust dir erstmal, neben dem Hauptwidget, dein Nachrichten- oder Textwidget.

Sollte in Etwa folgendes beinhalten. Bei mir habe ich das HUD_Messagebox genannt.

Wobei hier ja erstmal nur die Textausgabe, in diesem Fall txtMessage wirklich wichtig ist, für die Anzeige halt.

Du brauchst für meine Lösung noch eine Zwischenvariable Text als String. Kann man bestimmt auch optimaler lösen, aber ich habe es ja selber erst vor kurzem zurecht gebastelt. Muss man halt ausprobieren.

Dazu kommen noch zwei Funktionen. Wobei ich glaube das die eine, Get_txtMessage, glaube ich sogar automatisch erstellt wurde.

Die haben auf jeden Fall folgenden Inhalt.

SetTextInMessage

Recht überschaubar wie ich finde. Aber du musst der Funktion halt einen Input vom Typ String hinzufügen und den einfach zum Output durchschleifen.

GetTxtMessage

Hier wird der String einfach zu Typ Text umgewandelt.

Dieser Teil ist bestimmt noch optimierbar, weil es einfach Zwischenlösungen waren.

Was noch ganz wichtig ist. Du brauchst ein CustomEvent im Hauptwidget welches das Ganze verarbeitet.

Dies sieht wie folgt aus.

Ich habe es jetzt OnMessage genannt. Hier ganz wichtig die Reihenfolge. Erst kreierst du halt das Textausgabewidget. Dann steht dir auch der Zugriff auf die Variablen zur Verfügung. Danach setzt du den Text. Und dann wird halt mit AddChild hinzugefügt. Target ist hier die Messagebox. Ein Panel vom Typ Vertical Box, das die Nachricht aufnimmt. Bei dir vielleicht ein anderer Ort. Aber es sollte halt ein Panel sein damit du die Formatierung kontrollieren kannst.

Was ich dir auf jeden Fall empfehlen kann ist, leg dir eine Blueprint Function Library an. Die benennst du dann in WidgetControls um. Hier packst du alle Funktionen rein, auf die du über BP auf Widgets zugreifen möchtest. Also eine Art Hilfsbibliothek.

Die Funktion die du hier benötigst nennst du zum Beispiel Send_a_Message, die dann wie folgt aussieht.

Hier also auch ein Input vom Typ String. Bei Get All Widget of Clas wird unter Widget Class das Hauptwidget ausgewählt.

Und so wird es dann von einem beliebigen BP aus aufgerufen.

Ich hoffe ich habe jetzt an alles gedacht. War ja jetzt ein Schnellschuß. Aber im Zweifelsfall kann ich dir ja Fragen auch noch beantworten

Nicht verzagen.

Ich werde ja noch ein Tutorial dazu schreiben. Für das Tutorial werde ich das Projekt natürlich nochmal neu schreiben und wesentlich aufgeräumter und detaillierter beschreiben. Ich bin sogar gerade dabei.

Es dauert halt noch ein wenig, weil ich noch ein weiteres Problem, oder sagen wir mal ein unschönes Verhalten, lösen will.

Und dann dauert es natürlich noch etwas bis ich das Tutorial in Text und Bild umgesetzt habe. Das ist nämlich nicht immer ganz so einfach etwas verständlich zu formulieren. Was ja nun mal bei einem Tutorial nicht ganz so unwichtig ist.

Aber schauen wir uns mal deine Probleme an.

Pack einfach eine ReturnNode dran. Die kannst zwar nicht umbenennen, aber sie erfüllt denselben Zweck. Du darfst halt nicht vergessen, dass ich viel Ausprobiert habe bis es so funktionierte wie ich es haben wollte. Sprich da ist auch noch viel Test enthalten. Bei der neuen Lösung wirst du den Umweg in dieser Form vielleicht auch gar nicht benötigen.

Und Unity hat den ganz großen Nachteil das C# die Grundlage der Programmierung ist. Hier ist es C++, egal ob du direkt C++ programmierst oder über die Nodes.

Ich komme ja auch aus dem C# Bereich. Für Anwendungen auch echt gut, nur halt nicht für Spiele.

Du musst halt nur lernen, so wie auch ich, denn ich habe da auch noch meine Schwierigkeiten. Das siehst du an vielen Fragen die ich hier im Forum schreibe und einfach auf Denkfehler hinweisen.

Ich denke dir geht es da genau so wie mir, das du Nodes und BP im Kopf anders behandelst als du es in C# programmieren würdest.

In C# würdest du eine Klasse Message schreiben, mit all seinen Inhalten wie du sie haben willst.

Dann würdest du irgendwas in der Richtung schreiben:

TextAusgabe = new Message()
    TextAusgabe.Message = "Dein Text"
    TextAusgabe.Show()

Ist jetzt syntaktisch nicht ganz richtig, aber halt als Anschauung für Objektorientiertes programmieren.

Auch genau das vergisst man bei den Nodes immer das es genau so funktioniert.

Create HUD Message Box Widget würde dem Textausgabe = new Message entsprechen.

Set Text in Message entspricht TextAusgabe. Message = "Dein Text"

Und Add Child entspricht dann halt dem TextAusgabe.Show()

Wie gesagt, ich habe da auch meine Schwierigkeiten das so logisch zu sehen. Weil ich habe immer wieder das gefühl, als wenn die Nodes mehr machen würden als für einen Befehl zu stehen. Das ist aber nicht so. Es wäre auch sehr verherend, wenn die Nodes mehr wären als nur ein Befehl. Weil das würde die Flexibilität bei Blueprints enorm einschränken, so wie es eigentlich bei jedem Baukastensystem für Spiele ist. Die sind zwar erstmal auch einfacher. Aber man merkt halt schnell, dass sie dadurch auch sehr eingeschränkt in den Möglichkeiten sind.

Ach so, ich sehe auch gerade, dass ich einen Schritt vergessen habe. Also einer der mir jetzt aufgefallen ist.

Du musst in der Textbox natürlich noch den Text per Binding änderbar machen. Das würde dann die Funktion Get_txtMessage ergeben. So habe ich die Funktion dann halt genannt.

Vielleicht finde ich ja noch mehr was ich vergessen habe. Das ist durchaus möglich.

C# ist ja bekanntlich keine Compilersprache. Das hat wiederum zur Folge, auch in Unity, das du mit einem einfachen Programm den gesamten Quellcode wieder sichtbar machen kannst. Ich teile gerne hier was ich mit Unreal lerne in Form von Tutorials oder ähnlichem, jedoch vereinfacht dies ja auch dann das Hacken, wenn alles im Klartext vorhanden ist. Dazu kommt natürlich das C# auch etwas langsamer läuft, man muss bei Spielen schon extrem optimal programmieren.

Meine "Karriere" verlief im übrigen ähnlich, nur das du bei mir das ++ hinter dem C weg lassen kannst

Und C# ist ja auch recht toll, wenn es um normale Anwendungen geht. Nur in Spielen ist das Ganze natürlich auch Zeitkritisch zu programmieren.

Bei deiner letzten Frage. Das Level-Blueprint kann vieles beinhalten. Allerdings bin ich ein Freund davon nicht zu viel in ein Blueprint zu packen. Mehr modular zu arbeiten so weit es geht. Das siehst du auch an meinem Tutorial zum Tag-/Nachtzyklus. Extra BP, alle Komponenten rein die beeinflusst werden sollen und dann damit arbeiten. Hat den Vorteil das ich, wenn ich irgendetwas verhaue, ich das Modul einfach nur austauschen muss. Wenn ich jetzt direkt das Level-BP nehme, vielleicht noch im BP-Skysphere etwas reinpacke, dann suche ich nachher in 10 BP nach einem Fehler. Das ist aber nur momentan so meine Programmierphilosophie. Die kann sich auch wieder ändern, wenn ich darin einen Vorteil sehe, denn es ist nicht mehr und nicht weniger, eine Philosophie. Wenn ich feststelle das es nicht optimal ist, werde ich diese allerdings auch überdenken. Für Tutorials ist sie allerdings dann doch gut geeignet, weil man nicht immer zusätzlich erklären muss, was man in welchem BP macht.

Ich würde die Performance von c# jetzt in der aktuellen version nicht so allgemein verdammen. Aber ich glaube darum gings hier auch ursprünglich nicht was besser oder schlechter ist.

Von daher - level BP. Nein die variablen sind generell NICHT von anderen BP aus zugängig. Aber klar da man alles schön da als Referenz mit einem klick reinbekommt was man in den Level reinwirft verführt er ja vieles darüber zu machen. Der Trick ist die Richtung umzukehren. Nicht der actor BP fragt den Level BP ab - der Level BP schreibt jeden Tick den Wert in die Behelfsvariable die man in dem Actor jetzt anlegt.

Und Tomarr hat schon recht - nach Möglichkeit Level BP nicht überfrachten, wenn möglich modular BPs nutzen damit man sie recyclen kann ohne Aufwand.

Keine Sorge, so schnell macht die Unreal Engine keinen verrückt.

Oh, eine Autobahn mitten durch mein Wohnzimmer. Ja wo kommt die denn her?