Widget als Loading screen

  • Hallo Leute,


    ich möchte nachdem ein Spieler auf den dedicated Server gejoint ist, sofort ein Widget anzeigen, damit der Spieler nicht sieht, wie die Spielobjekte nach und nach gespawnt werden. Das soll sozusagen als Loading screen dienen. Wenn ich das im PlayerController auf BeginPlay Spawne und hinzufüge, dann sehe ich etwa für 1 Sekunde, wie sich im Hintergrund die Welt aufbaut.


    Kennt jemand eine Möglichkeit ein Widget sofort als erstes zu spawnen, noch bevor irgendein Begin Play aufgerufen wird? (im Constructionscript lassen sich Widgets leider nicht spawnen) Levelblueprint hab ich auch schon versucht.


    Edit:

    Aktuelle Lösung ist folgende: OnPostLogin wird auf den PlayerController ein reliable custom event zum client geschickt, dort dann sofort das widget geadded. Jetzt hab ich noch etwa 1-10 Frames lang den Hintergrund im Blick, bevor beinahe sofort der LoadingScreen erscheint. Mehr Latenz bedeutet hier mehr Wartezeit auch auf den Loadingscreen. Falls also noch jemand einen magischen Trick kennt, wie man auch diesen Bruchteil einer Sekunde wegmachen kann, immer raus damit :D

  • Ich weiß leider nicht ob das in Blueprint möglich ist.

    Ich musste C++ dafür nutzen.


    Für normale Map Travels muss der Loading Screen über ein extra LoadingScreen Modul gezeigt werden. Dieses Modul wird beim Laden nicht blockiert.


    Bei einem Seamless Map Travel (z.B. server wechselt die map ohne Spieler zu kicken) muss dann aber über ein Slate/UMG Widget gearbeitet werden. In meinem Fall war es ein Slate Widget, damit sich das Loading Screen Modul und meine Viewport Klasse das gleiche Widget Teilen.


    Genaueres kannst du sehen, wenn du den Quellcode von dem ShooterGame example anschaust. Dazu musst du aber gutes C++ und UE4 Architektur Verständnis haben.

  • Wie wäre es mit einer anderen Herangehensweise ? Du könntest das mit Sublevels lösen.


    1.Du lädst ein leeres Mainlevel

    2.Dann lädst du direkt das Menü ins Mainlevel

    3.Nachdem das Menü geladen ist, lädst du das eigentliche Level ebenfalls als Sublevel.

    4.Das eigentliche Level kannst du dann auch erst anzeigen wenn es komplett geladen ist.

    5.Ein weiterer Vorteil wäre, dass du beim Leveltausch auch dieses direkt ins Mainlevel laden kannst und das alte Level ausladen kannst.


    Der Vorteil ist, dass das Level bereits weiter geladen wird solange du dich im Menü aufhälst.

    Du kannst am Anfang auch die Anzahl der Objekte einmal zählen und daraus ein Ladebalken basteln.

    Mit tut jeder Mensch Leid, der nicht genug Phantasie hat, um ein Wort mal so und mal so zu schreiben.

    Mark Twain

  • Ich möchte mich nicht festlegen, aber das wird meiner Einschätzung nach nicht gehen, wenn es um das joinen des Servers geht. Selbst wenn du auf der Map A bist und der Server ebenfalls auf Map A ist und du dann joinst, wird sie trotzdem neu-geladen, da sie ja schließlich einen anderen Zustand hat oder haben kann

  • Ich habe jetzt den Ansatz von Tomura fertig umgesetzt, funktioniert tadellos und ich hab noch was gelernt dabei. Ich wusste gar nicht, dass man vom allseits beliebten Viewport erben und sowas damit anstellen kann. Geschweige denn von den abgefahrenen Delegates, die im ShooterGameInstance verwendet werden. Danke vielmals, für die interessanten Ansätze, das mit dem Post Process schaue ich mir auf jeden Fall auch mal an, das klingt interessant.

  • Ich habe jetzt den Ansatz von Tomura fertig umgesetzt, funktioniert tadellos und ich hab noch was gelernt dabei. Ich wusste gar nicht, dass man vom allseits beliebten Viewport erben und sowas damit anstellen kann. Geschweige denn von den abgefahrenen Delegates, die im ShooterGameInstance verwendet werden. Danke vielmals, für die interessanten Ansätze, das mit dem Post Process schaue ich mir auf jeden Fall auch mal an, das klingt interessant.

    Ja man kann die recht viele Engine Klassen vererben, was ich z.B. gemacht habe um bei Travel/Network failures entsprechende Nachrichten im GUI anzuzeigen, etc.