Beiträge von Annubis

1. stell in den Scene Settings im Blender die Einheiten auf Metric und die Scale auf 0.01. Dann speicherst du die Standard Scene ab, beim nächsten laden von Blender merkt er sich die Einstellung. Die Angaben stimmen dann mit Unreal 1UE = 1 Meter. Damit lässt sich in Blender einfacher arbeiten.

2. UnWrapping haben die Jungs hier schon fast alles gesagt, da hilft am Ende nur probieren. Bei komplexen Figuren/Objekten brauchst oft auch mehr als eine Textur und die bekommst du indem du in Blender verschiedenen Flächen unterschiedliche UVs zuteilst.

3. Texturieren kannst du in Blender direkt, egal ob du auf dein Objekt malst oder Texturen direkt einer UV zuweist. Seit der 2.8 ist es in Blender auch extrem einfach direkt auf das Objekt zu malen auch wenn es in Substance natürlich noch komfortabler ist.

Für sowas würde ich einen VerwaltungsBP machen, dann kannst in nem Charakter das freischalten, was du brauchst, außerdem wird die Handhabung einfacher, wenn du Fähigkeiten oder Stärken anpassen willst.

Skillsysteme werden erst erstellt und dann kannst du die Implementierung vornehmen, aber bei 1330 Skills drängt sich ein VerwaltungsBP vielleicht mit Zugriff auf SQL oder etwas ähnlichem auf.

Zitat von Tomarr

Ich glaube schlichtweg das ich ein Fehler im Interface habe, welches dafür sorgt, dass die ganze Kette quasi als eine Einheit erkannt wird. Das habe ich noch nicht ganz raus.

Das kann nicht sein. Dein Interface muss ja einen Identifikator haben, um zu wissen, wohin der die Information schicken soll und die setzt du in dem Moment, wo du Kabel anschließt. Jedes Kabel hat eine eindeutige Kennung, was du schon daran siehst, wenn du mehrer Kabel in deine Scene ziehst, dann erhalten sie immer einen eindeutigen Namen.

Ist ein Kabel nicht angeschlossen, dann erhält es keinen Identifikator und geht ins Leere. Andernfalls wird dein Signal über beliebig viele Kabel an den Empfänger per Interface weitergeleitet.

Wenn du etwas als "Einheit" festlegen willst, dann ist das wesentlich schwerer oder du hast den Identifikator nicht richtig gesetzt.

Du schriebst was von Brücken und Doppelbelegung. Da gehört ein bisschen mehr dazu. Bei den normalen Gateways geht nur jeweils eins, daher genügt dort auch immer 0 und 1. Grundlagen der Logikschaltungen.

Im AND Gate gibt es 3 Variablen A / B und O. Variable A und B können nur 0 oder 1 sein und sind standard auf 0. Folglich ist O (output) immer 0. Ist eine Variable 1 ist etwas angeschlossen und ein Signal vorhanden. Sind beide Variablen 1 dann sind beide angeschlossen und O ist 1.

Wenn du das mit Kablen machen willst, brauchst du noch die Abfrage isValid. Ist kein Kabel angeschlossen, dann ist die Variable leer. Ist ein Kabel angeschlossen dann hat die Variable einen Wert (meist 0).

Beim Schalter gibt es nur O (output). Ist die Variable leer dann ist kein Kabel drann. Wenn ein Kabel drann ist, dann ist die Variable o = 0 und wenn du den Schalter einknippst, dann ist die Variable O =1.

Dein Kabel hat zwei Anschlüsse. Einen Input I und einen Output O. Wenn du den Schalter umlegst und beide Anschlusse verbunden sind, dann erhalten beide Variablen I/O den Wert 1 und dein Kabel leitet den geänderten Wert an das nächste Kabel oder das nächste Gate weiter.

Ich versteh dein Problem noch nicht so ganz. Die Eingangsvariablen haben entweder keinen Wert oder 0 bzw. 1. Kein Wert bedeutet kein Anschluss. 0 bedeutet kein Signal, 1 bedeutet Signal. Damit bildest du die typischen Logikgates ab. du musst doch nur isValid prüfen und wenns das ist, schauen obs 0 oder 1 ist.

Was dir fehlt, ist das Verständnis, wie BP miteinander communizieren.

Egal was du machst. Es gibt immer mindestens zwei Blueprints. Wenn du von einem ins andere "funken" willst, dann musst du immer dem ersten Blueprint (Sender) sagen, wo er hin funkten soll. Bei all deinen Screenshots fehlt dieser Punkt.

Ein Widget ist letztlich auch nur ein Blueprint, der auf bestimmte Funktionen beschränkt ist. Klickt man auf einen Button, muss man dem Button immer sagen, welches andere Blueprint er anfunkten soll. Bei "CastTo" gibt es dafür ein "Target" und dort musst du dein Zielblueprint angeben.

Ein Interface funktioniert genau auf die selbe Weise, wie ein CastTo von der Grundlogik nur dass du dort unendliche Variablen mitschicken kannst und diese im ZielBP verarbeitest.

Als Tip: Wenn du anfängst in einem Widget Logiken abzuarbeiten, dann machst schon was falsch. Widgets dienen auschließlich dem Nutzer zur Kommunikation mit dem Spiel. Sie sollen niemals Spielelogiken abarbeiten, das macht immer ein BP im Hintergrund.

Dean Ashford macht gute Tuts zu einzelnen Problemen

Underscore ist da auch recht gut.

Mathew Wadstein - bester überhaupt. Erklärt fast alle interessanten Nodes.

Wenn ich das richtig verstehe, müsstest du dem Server sagen, dass er beide Level/Maps laden muss.

Meiner Meinung nach fängst du bei keinem der genannten Dinge an. Als erstes lässt du die UE4 und 3D-Programme aus.

Dann nimmst dir entweder ein altmodisches schön großes Blatt Papier oder ein Programm wie OneNote und machst bzw. malst dir ein Konzept. Definiere deine Ziele. Was soll möglich sein? Welche Eigenschaften benötigen die Objekte und Charaktere deines Spiels. Wie soll gespeichert werden. Gibt es eine Kampagne oder eine Story. Was ist ein Sandboxmodus. Was soll im Multiplayer möglich sein. Wie läuft die Tastenbelegung für welche Features. Wie groß sollein Level oder die Map sein. Welche Assets benötige ich fürs Design.

Wenn du das alles im Konzept hast, dann kannst du auch entscheiden mit was du anfängst.

Kein Konzept bedeutet meistens Chaos bei der Entwicklung. Siehst du auch oft, wenn Entwickler Konzeptzeichnungen zeigen, dass die Vorbereitung oft sehr viel Aufwand birgt, bevor überhaupt irgend etwas programmiert wird.

Dein Objekt bekommst du aus dem Overlap (roter Kasten am Anfang). Da solltest du mindestens aus "Other Actor" eine Line ziehen können und dann cast to benutzen. Das zu referenzierende Objekt muss ja das Ereignis "Overlap" auslösen und ist damit identifizierbar.

Set und Clear Nodes benutzen....

Hast du schon richtig verstanden. Streaming hat nicht so sehr etwas damit zu tun, was die Grafikkarte berechnen muss, sondern damit, wieviel Ressoursen zur Verfügung stehen. Grafikkartenspeicher und Arbeitsspeicher werden entlastet, was gerade bei großen Karten merklich ist. Auch einzelne Layer können davon betroffen sein.

LOD ist das Reduzieren des Polycounts und der Textur. Culling ist das darstellen eines Objekts. Streaming ist das Löschen oder Laden einer gesamten/einzelnen Szene/Map.

Ist jetzt sehr sehr allgemein. Nur zum Verständnis.

Was ich grad nebenbei bisschen teste, ist streaming. Die Funktion sollte man neben den LOD nicht so ganz unterschätzen. Besonders wenn man geschlossene Räume hat, ist Streaming sehr genial und man kann auch mal etwas mehr Details darstellen, bevor es Probleme mit der Performance gibt.

Der Radius ist der halbe Durchmesser?! Im BP also durch ne simple Berechnung anpassbar. Versteh dein Problem nicht so ganz.

CastTo nutze ich nur, wenn es um Variablen anderer BP geht, Interfaces, wenn der andere BP eine Berechnung oder Interaktion durchführen soll. Liegt meiner Meinung nach auch schon in der Übersetzung der beiden Sachen. Das man beides für so ziehmlich alles nehmen kann, stimmt sicher, aber wie elegant und vor allem logisch es dann ist, muss jeder selber entscheiden.

Interaktionen mit Objekten läuft bei mir immer über ein Interface.

CastTo ist eine Änderung des Variablentyps? Ich versteh nicht, was du nach dieser Aussage schreibst. Hab es jetzt dreimal gelesen, komm aber nicht dahinter.

CastTo = Auslesen/Ändern einer oder mehrer Variablen eines anderen Actors.

Interface= Auslösen von Code in einem anderen BP mit der Möglichkeit Daten zu versenden.

Für alles was Tasten und Tastenkombinationen angeht, hab ich Macros gemacht. Warum willst des nicht nutzen?

Klar geht das auch mit Gras. Es ist genau wie ein Baum nur ein Bestandteil des Foliage. Ermittel die Komponenten der Fläche auf der du etwas bauen möchtest, sammel alle Bestandteile des Foliage auf dieser Fläche, speichere sie in einem Array ab und lösche sie. Wenn das Gebäude später abgerissen wird, lade die Postion und das Gras wieder zurück, oder lass es wachsen. Es gibt rein von der logischen Seite keinen Unterschied zu einem Baum.