Fadenkreuz und Objekte

    Interface wird ja mit Schnittstelle im Sinn übersetzt und genau das ist es letztlich auch in der Verwendung.


    Im Interfaceblueprint kannst du mehrere Schnittstellen festlegen. Folgende Beispiele:


    Interaction (Taste E/F drücken)
    CallInfo (Das Object zeigt im Widget Infos über sich selbst)
    Highlight (Object bekommt einen Umriss)


    Im LineTrace kannst du jetzt sämtliche Interfaces abfeuern lassen. Das Object welches anvisiert wird, wird natürlich nur diejenigen Interfaces ausführen, mit denen es Verknüpft wurde. Enthält es keine (Landscape) dann passiert auch nix.


    Trifft es ein Object mit "Highlight"-Interface, wird das Object umrandet aber keine CallInfo oder keine Interaction (F) ist möglich.


    Trifft es auf ein Object welches mit allen Interfaces verbunden ist, dann funktionieren auch alle 3. Eine Abfrage im LineTrace ist daher auch nicht notwendig.


    Als Beispiel für ein HighlightInterface ist zum Beispiel das versenden eines TagArrays. Je nachdem welche Erfolge ich im Spiel erhalte wird dieser Erfolg gespeichert. Dann prüft beispielsweise das Highlightinterface im anvisierten Object, ob ich einen Erfolg habe oder nicht. Da ich direkt versende, benötige ich keinen CastTo. Das Object kann einen direkten vergleich starten, ohne eine Rückfrage stellen zu müssen.


    Ich selbst verwende dieses System beim Ressourcenabbau. Je nach SkillLevel kann ich verankern, welche Erze ich abbauen kann. Wird der Erfolg "Kupfer" gesetzt kann ich als Interaction sodann auf Kupferbrocken einschlagen, und erhalte Rohstoffe. Auf Platinvorkommen kann ich das allerdings nicht, sodass ich diesen nur als einfach Object im Spiel wahrnehme.


    Die Einsatzmöglichkeiten sind im Grunde endlos, da auch die Informationen die ich im Interface verankere individuell anpassbar sind. Im anvisierten Object habe ich auch keine Sorgen mit CastTo, da mir die Informationen erst gegeben werden wenn es zum Aufruf des Interface kommt.

    Wow, so habe ich das noch nie in Betracht gezogen.
    Klingt nach einer super Sache! Und man kann dann abfragen welche Interfaces ein Objekt besitzt oder wie macht man das? gibts dafür eine Node?
    Ich habe mich bisher noch nicht intensiv mit Interfaces beschäftigt. Möglicherweise könnte ich so mein Bausystem verbessern.
    So wie es klingt hat man so auch eine leicht bessere Performance, da man nciht ständig casten muss oder?

    Zitat von Darkentik

    Wow, so habe ich das noch nie in Betracht gezogen.
    Klingt nach einer super Sache! Und man kann dann abfragen welche Interfaces ein Objekt besitzt oder wie macht man das? gibts dafür eine Node?
    Ich habe mich bisher noch nicht intensiv mit Interfaces beschäftigt. Möglicherweise könnte ich so mein Bausystem verbessern.
    So wie es klingt hat man so auch eine leicht bessere Performance, da man nciht ständig casten muss oder?

    Im Grunde muss man garnicht CastTo benutzen. Es gibt auch keine Node, denn die InterfaceNames legst du im Interface BP fest. Da legst du auch fest, welche Variablen mit dem Interface versendet werden. Rufst du dann im EmpfängerBP das Interface was du selbst benannt hast auf, dann bekommt er als Auswurfvariablen alle die verpasst, die du festgelegt hast. Das Interface musst du nur in den Details zuweisen. Fertig.


    Der Vorteil ist, dass du das gleich im MasterBP machen kannst und so alle Childs das Interface vollautomatisch bekommen. Auch das nachträgliche Einfügen hat bei mir bis jetzt immer problemlos funktioniert.


    Das Interface erscheint nach der Erstellung natürlich erst, wenn du compilierst und speicherst. Wie bei allem anderen selbsterstellten auch.


    Hier nochmal zwei Screenies, wie das ausschaut. Links ist der CharacterBP mit nem normalen LineTrace und rechts dann das BP des jeweiligen Assets. Auf dem rechten Screeny sieht man auch , dass man auf ClassSetting switchen muss (oben) damit man dann rechts in den Details die Interfaces erhält. Die Events können dann ganz normal verwendet werden. Schaut man aufs Objekt und ist was Verknüpft, dann wird es erst umrandet. Mit E kann man es beispielsweise aufsammeln oder mit LMB kann es attackiert oder abgebaut werden.

    War ja auch ursprünglich nicht die Aufgabenstellung. Die Reaktion des Objekts wird ja repliziert, nicht das Trace. Kommt halt auch immer darauf an, was über das Interface läuft. Das Abbauen eines Objektes bedarf ja der Korrektur aufm Server nicht das Interface. Aber das is ne andere Baustelle. Netzwerkfähig is das Beispiel nicht. Nur mal so hingestellt, um eine Idee davon zu bekommen, was funktioniert.

    Zitat von Dj EKI

    @Annubis braucht ein Titel, der Interfacer! :D

    :D :D :D :D :D :D :D :D :D


    Ich find das UE-Vid schon schön, das hätten sie mal weit eher machen können. Das mag zwar alles am Anfang sehr trocken sein, aber gerade solche Grundlagen halte ich immer für wichtig. Man entwickelt dann mit der Zeit ein Problemlösungsverständnis, was ohne solche Grundlagen meistens nach hinten losgeht.


    Am Anfang stand ich vor den EventDispatchern mit fünf Fragezeichen. Mittlerweile liebe ich die Dinger, weil sie einfach sehr vieles vereinfachen, insbesondere Dinge, die eher unscheinbar im Hintergrund laufen. Die Benutzung von EventTick ist dadurch von 90% auf 5% gesunken. Nur beim Bausystem und beim Trace hab ich es noch drinn. Alle anderen bedingungsgesteuerten Events laufen über CastTo, Interface und EventDispatcher.