Beiträge von Phoenix-100

    Danke DarkFaces für deinen Input. Ich sehe da keinen grossen Unterschied.

    Du machst es über Interfaces Messages. Zugegeben, deine Lösung ist kürzer.

    Persönlich bevorzuge ich meinen Weg weil ich diese Funktion direkt aufrufen kann ohne messages und genau weiss auf welchem Objekt ich jetzt etwas mache und so könnte ich auch die Referenz sauber halten. Das würde dann auch Performance sparen. Zudem ist es eher der konventionelle Weg wie Interfaces verstanden werden. Das ist nicht auf das Beispiel bezogen und nur meine persönliche Meinung.


    Gruss

    Hallo zusammen


    Feal das freut mich sehr!

    Also die InteractionCapsule ist einfach eine weitere Capsule Component die etwas nach vorne gerichtet ist. So stelle ich fest was für Objekte sich vor dem Character befinden. Das musst du am besten zuerst einmal ausprobieren, dass du sicherstellt dass das overlapping richtig funktioniert. Also einfach einmal alle overlapping Objekte ausgeben und sicherstellen, dass dein Tisch auch tatsächlich darin enthalten ist.


    Dass der Cast nach dem Interface fehlschlägt ist durchaus normal, wenn es andere Objekte sind die das Interface nicht implementiert haben. Du kannst ja den Namen des Objektes ausgeben. Wenn du das interface richtig hinzugefügt hast, funktioniert auch dieser Cast zwingend.


    Gruss

    Wirklich sauber kann ich dir das nicht zeigen, aber hier ganz kurz und einfach.

    Per Interface:

    Ich habe das ThirdPersionStarter Projekt genommen. Hier ein Actor_BP gemacht namens Tisch. Hier gibt es eine weiter Komponente Namens Hebel. Beides muss repliacted aktiviert haben. Hier gibts eine Funktion "betaetigen". In dieser Funktion passiert die tolle Aktion mit dem Hebel. Ich gebe hier einfach einen String aus und rotiere den Hebel rudimentär.



    Dann haben wir den Character der mit der E-Taste mit diversen Dingen interagieren möchte. Also mit diesem Tisch, mit der Tür, mit NPCS usw.

    Dazu erstelle ich zuerst ein Interface mit dem Namen E-Interaction. Hier gibt es nur eine Funktion namens E-Pressed. Sonst komplett leer wie du in dem Bild siehst.



    Der Tisch implementiert dieses Interface und ruft die Hebel Betaetigen Funktion auf.



    Nun können wir das im Character ganz einfach ausführen. Ich nehme die Objekte mit dem der Character überlappt, cast nach dem Interface und rufe die E-Pressed funktion, die ich vorhin im Interface leer erstellt habe, auf.



    Wenn jetz der Character mit einem Objekt überlappt, kann die Aktion mit E ausgeführt werden.

    Dabei ist es egal was das für ein Objekt ist. Mit allen Objekten, die das Interface implementieren können wir nun interagieren.

    Du kannst jetzt also eine Tür machen, das Interface implementieren und es funktioniert, am Character musst du nichts ändern und an den anderen Objekten auch nicht. Funktioniert so auf dem Server und den Clients. Cool oder?



    So viel zum Interface.

    Jetzt könnten wir das auch per Vererbung machen,

    Ich erstelle einen neuen Actor_BP und implementiere alle Aktionen auf die ich reagieren möchte.

    In diesem Fall nur per E-Pressed. Die Funktion bleibt aber leer hier.



    Der Tisch nun erbt von diesem BP. Wenn du einen neuen BP erstellt musst du immer einen Parent wählen. Wenn du Actor auswählst, heisst das, dass dein neuer Blueprint vom Actor erbt. Du hast also Vererbung schon verwendet. Du kannst also durch das Erstellen eines neuen BP direkt erben oder du änderst es bei einem bereits existierenden Blueprint unter File -->Reparent Blueprint.

    Der Parent vom Tisch ist jetzt hier der neue InteractionObject_BP und nicht mehr Actor wie zuvor beim Interface Beispiel.

    Nun kannst du die Funktion E-Pressed überschreiben. Überschreiben heisst du Funktion vom Parent mit einer eigenen ersetzen oder erweitern. Das sieht wie folgt aus.


    Im Character können wir nun nach dem InteractableObject Casten, von dem der Tisch erbt und die Funktion aufrufen.


    Der Vorteil ist jetzt hier, die Türe kann auch von diesem InteractableObject erben. Das heisst du musst im character nichts ändern und kannst mit tausenden von verschiedenen Objekte interagieren.


    Das ist jetzt hier etwas gar schnell entstanden und nicht besonders sauber. Aber ich hoffe du siehst wie es funktioniert.


    Gruss

    Hallo


    gut dass du das Problem lösen konntest.

    Du kannst es auf dem Stellblock per Default nicht ausführen. Auf dem Client kannst du Funktionen auf dem Server nur auf Objekten ausführen, die eine owning connection haben, also sozusagen dem Spieler gehören.


    Der Spieler muss also die Funktion auf dem Stellblock auslösen, und zwar auf dem Server. Das machst du ja jetzt auch.

    Das Problem mit dem Cast ist aus meiner Sicht aber, dass der Spieler vermutlich mit vielen, vielleicht tausenden von Objekten im Spiel interagieren möchte und du willst nicht alle versuchen zu casten. Persönlich löse ich das am liebsten mit Interfaces. Vererbung wäre auch möglich.


    Viel Erfolg.

    Gruss

    Der letzte Screenshot kann ich leider nicht lesen und konnte dem Code noch nicht folgen.

    Zunächst einmal, könntest du bitte kontrollieren, dass beim Tisch mit dem Hebel:


    1. Dass der Actor die checkbox replicated aktiviert hat.


    2. Dass die Componenten checkbox Component replicates aktiviert haben.


    3. Ob du eine Warnung im output log hast?


    Multicast brauchst du von mir aus gesehen nicht.


    Gruss

    Also zunächst einmal sind das zwei verschiedene Dinge. Das Anzeigen des Textes solltest du lokal machen, das interessiert den Server nicht und die anderen Spieler auch nicht.


    Das Umlegen des Hebels hingegen interessiert alle, also den Server und auch alle anderen Clients, also im Sinne von, wenn Spieler 1 den Hebel bewegt, muss er sich überall bewegen.

    Das heisst diese Funktion muss der Server ausführen. Der Client darf das nämlich nicht selbst tun (wegen cheaten).

    Der Client muss also dem Server sagen "ich möchte jetzt hier den hebel umlegen", wenn der Server sagt, ja das ist OK, nur dann wird der hebel vom server bewegt. Wie geht das?

    Du brauchst ein Event das "run on server" ist. Dieses Event führt dann die Aktion aus. Damit alle Clients das wiederum sehen, muss dieser Hebel und der Actor der ihn Besitzt auf "Repliacted" (checkbox) gesetzt sein. Dann wird es zurück auf alle Clients repliziert.

    Also Client ==> Server ==> All Clients.


    Gruss

    Hallo


    Sieht mir nach einem Replication Problem aus. Der ganze Prozess mit diesem Text muss den Server überhaupt nicht interessieren, dass reicht alles lokale ohne replication. Woher callst du das Schau Drauf Event?
    Kannst du ein Screenshot hochladen vom Components tab mit dem griff selected?


    Gruss

    Du willst es wohl deaktiveren.

    Soweit ich weis gibt es die Option nicht mehr.

    Stattdessen kann du in 4.25 Launch as Seperate Server auswählen, dann wird ein Server gestartet, selbst wenn es keinen bräuchte. Dann kannst du Play Net Mode Offline setzten und hast den selben effekt, wie ein deaktivertes auto Connect, damit musst du dich um das connecten selber kümmern.

    Damit das als ein "Konstrukt" angesehen wird gibt es mehrere Möglichkeiten. Bleiben wir einmal bei BP, als da wären unter Anderem die ChildActorComponents, dann einfach StaticMeshComponents und HISM die du nutzt.

    Generieren wir mal Objekte mit allein drei Optionen, zuerst spawme ich die Cubes mit HISM, dann mit ChildActorComponents, und zuletzt noch mit StaticMeshComponents.




    Das sieht alles gleich aus, oder?

    Im Grunde ist der Prozess ja bei allen sehr ähnlich, aussehen tun diese auch gleich.

    Der Unterschied ist vor allem die Performance und die jeweiligen Möglichkeiten.

    HISM performt am besten weil es sich um Instanzen handelt, dafür sind die Möglichkeiten eingeschränkt. Glücklicherweise muss eine Wand in der Regel auch nicht viel mehr tun als Wand sein. Schwieriger wirds bei Gameplay Elementen.1

    Du siehst auch, dass LODs unabhängig bei allen funktioniert.


    Gruss

    Hey zusammen

    Beim Procedural Runtime Generieren haben die Designer einfach wenig bis keine Kontrolle wie die Map nachher aussieht,

    denn nach der Session sind die Objekte ja weg entsprechend muss dann alles zur Laufzeit generiert werden.

    Wenn man das im Editor macht, hat man jedoch beides, das Grundlevel Procedural und danach manuell verfeinern. Das Level sieht dann aber immer gleich aus, es macht das erstellen einfach schneller.

    Die Objekte werden da einfach beim Construct schon generiert. Wenn ich Druusch richtig verstanden habe, klappt das ja auch,

    nur die Platzierung scheint das Problem zu sein, da ist wohl irgendwo ein Fehler drin.

    Mit so wenig Informationen kann man aber kaum raten.

    Die Idee mit HISM verstehe ich nicht, einerseits sind ChildActors nötig und dann reicht doch HISM, wenn das reicht,

    wozu die Child Actors?

    Hier ein Beispiel von mir mit Random Generierten ChildActors im Editor, das coole daran ist, man kann so oft Generieren bis es passt und danach einfach alles bewegen bis es am richtigen Ort ist. Wenn man viele Level erstellen muss geht das auch viel schneller.


    Du nutzt also Dedicated Server und nicht Listen Server. Meine Antwort bezog sich auf letzeres.

    Gibts ein Grund für das Multicast? Falls nicht lösch es raus und verbind das Spawn Actors Zeug direkt mit dem Server Event und warum rufst du, nachdem du Spawn Actor auf dem Server aufgerufen hast, nochmals lokal spawn Actor auf? Zuletzt, hast du in der Konsole Warnings (no owning connection)?

    Hey


    Dein Server ist gleichzeitig auch ein Client, zumindest wenn du einfach die Spielanzahl beim Play Button auf zwei erhöhst. Wichtig sind zwei Dinge, dass die Box vom Client 2 auch auf dem Server gespawnt wird und nicht auf dem Client 2, weil er sonst nicht replicated wird (Sicherheit) und zweitens, dass die Box auch die Replicated checkbox gesetzt hat. Also Actor auswählen und dort prüfen, dass alles notwendigen Repliacted Checkboxen auf True setzen.


    Gruss