Beiträge von dlay

Ach stimmt ja, Mixamo wurde ja von Adobe gekauft. Nun wenn die Vielfalt an Möglichkeiten noch so groß ist wie die damaligen Inhalte der kostenpflichtigen Version, dann ist das doch eine super Möglichkeit für den Anfang.

Hallo und Willkommen!

Fuse ist mit der beste Creator den ich kenne, was die Qualität angeht, da bekommst du auch direkt die passenden Rigs und Animationen, aber natürlich nur gegen Bares. EDIT: zur Zeit kostenlos.
Es gibt ansonsten noch von Autodesk einen Creator, die Auswahl an Modellen und Kleidung ist allerdings eher gering. Die Chars sind auch geriggt, ohne Animationen. Kostenlos.
Wenn es nur das Basemesh braucht, ist Makehuman auch noch eine Alternative, damit kannst du relativ leicht die Körperproportionen festlegen und dann im nächsten Schritt Kleidung selbst erstellen. Rig vorhanden, Animationen nicht. Kostenlos.
Dann gibt es noch, falls du der Besitzer einer ZBrush-Lizenz sein solltest, dafür auch noch diverse Plugins, mit denen man Korperproportionen einfach festlegen kann. Von dort aus (Kleidung, Rig, etc.) musst du natürlich wieder alle sselbst machen.

Das waren alle die ich kenne. Aber nochmal eine wichtige Anmerkung zum Schluss: Empfehlen würde ich einen solchen Workflow allerdings nur für eher unwichtige Nebencharaktere und dergleichen, da die Ergebnisse immer (außer vielleicht bei der letzten Methode) sehr generisch sind und nicht wirklich als Basis für Hauptcharaktere, die immerhin dein Spiel tragen (sowohl grafisch als auch im Hinblick auf die Story), geeignet sind.

Das Thema ist ja nun schon so alt wie das Forum. Ich fände natürlich ein Forum mit aktivem Admin wie Exclusive auch besser nur würden wir dann vor dem Dilemma stehen, dass bei einem "Umzug" dieses Forum ja weiter besteht und für neue Benutzern vermutlich weiterhin erste Anlaufstelle aufgrund der bisherigen Aktivität und des Google-Rankings sein. Sofern man also nicht aggressiv die Leute von hier auf das neue Forum weiterleitet, und das eine Weile lang, schaden wir der Community nur indem wir sie aufspalten.

Ich melde mich dann mal zurück.

Das ist eigentlich so nicht ganz richtig, denn ich habe mich ja (unfairer Weise) gar nicht abgemeldet. Das ist mitunter der Tatsache geschuldet, dass ich das letzte halbe Jahr aufgrund familiärer Streitigkeiten nicht an der Uni bleiben konnte und ich auch alles andere erstmal runtergefahren habe. Das entschuldigt zwar nicht, dass ich wortlos plötzlich weg war, aber so ist nun mal der Stand der Dinge (gewesen).

Jetzt bin ich auf jeden Fall wieder im Studentenwohnheim und voll dabei, ob ich an meinem alten Projekt weitermache oder bei anderen einsteige/etwas neues mache, weiß ich noch nicht genau, ich guck mir erstmal die Neuerungen von v10 und v11 an.

Ah sorry das hatte ich sogar selbst gewusst (User Set gedöns), nicht dran gedacht. Naja, jetzt hast du es ja.

Also zunächst wär es denke ich mal hilfreich wenn du nicht die Mauslocation als Ziel nimmst, sondern beim drücken des LMB LineTraceByChannel zur Mauslocation machst um den tatsächlichen Hitactor zu finden, sonst feuerst du unter Umständen durch Gegner und Wände durch. So kannst du auch (ich weiß ja nicht was du so planst) einfacher an andere Actors dahinter kommen, wenn du z.B. durch ForceShields bzw. durch mehrere Gegner hindurch schießen willst. Aber das nur so am Rande.
EDIT: nvm, ich seh grad mit der Maus kann man auch mehrere Hits generieren

Ansonsten hab ich mal kurz mir diese BeamTarget/Source Sachen angeguckt, hast du denn im ParticleSystem selbst da alles für drin? Also BeamData, sowie Source und Target?

Tja also ich hab auch schon Weapon Trails realisiert und da benutze ich die Funktion Set Vector Parameter (also auf deinem "Blitz") und da halt den EndPoint rein, fertig. Allerdings wär das dann wahrscheinlich eher ein einmal Beschuss von Partikeln, da sich der Ursprungsort ja nicht verändert. Ich probier nochmal bisschen rum.

Die Variable die dafür zuständig ist (zumindest wenn ich dein Problem richtig verstanden habe), ist die GroundFriction in der CharacterMovementComponent.

Ich hab mit BeamSource/Target noch nichts gemacht, aber wenn ich mir so dein BP angucke würde ich sagen das Problem liegt darin, dass sich der ParticleEmitter immer nach der Rotation orientiert und die setzt du nur einmal, nämlich bei Beginn des Tastendrucks, dementsprechend würde der Blitz sich immer in die selbe Richtung zeigen. Bzw. in Richtung des Controllers (Warum?). Aber wiegesagt, mit diesen BeamTargets hab ich noch nichts gemacht von daher keine Ahnung ob das sich da in die Quere kommt oder nicht.

Ich war anfangs auch von Survivalspielen begeistert, fing bei mir mit DayZ an und war anfangs auch sehr cool. Das Problem was ich nur mit solchen Survial Multiplayertiteln habe ist, dass sie in der Praxis einfach nicht so funktionieren wie man es gern hätte.
Neustes Beispiel: die Präsentation von Ubisofts "The Division". Für diejenigen die die Szenen von der E3 nicht gesehen haben, es zeigt eine Gruppe von 3 Spielern, die durch die verwahrloste Stadt laufen und auf 2 NPC Feinde treffen, sich dafür eine Vorgehensweise überlegen. Plötzlich tauchen 2 weitere Spieler von hinten auf und eröffnen das Feuer auf die NPCs. Die 3er Gruppe hilft mit und dannach begeben sich die 5 Spieler gemeinsam zur Dropzone, wo sie vom Helikopter abgeholt werden. Dort angekommen entschließt sich die 3erGruppe, die 2 neuen Spieler zu erschießen und deren Beute an sich zu nehmen. Das gelingt auch, einer der 3 wird jedoch verletzt. Der Spieler (dem die Zuschauer zusehen, als quasi wir) nutzt diese Gelegenheit aus, verlässt die Gruppe ebenfalls und tötet seine Kameraden und entkommt mit der gesamten Beute.

Die Menge tobt, die Mischung aus Vertrauen und Verrat in Survivalspielen lässt das Höschen feucht werden und man freut sich sowas selbst Spielen zu können. Doch gibt es dabei ein Problem: Wie immer kann es eben nur einen Gewinner geben, nur einer kann alle anderen umbringen, den Loot kassieren und hat Spaß, alle anderen Spieler müssen darunter leiden. Der Spaß des Gewinners kommt nur auf Kosten der anderen Spieler zu stande. Das funktioniert in der Praxis genau solange, bis sich der Verlierer eingesteht, dass er nun auch mal überleben will und kommt zu dem Entschluss, dass er nur eine reelle Chance hat, wenn er andere Spieler bereits bei der ersten Begegnung angreift. Denn nur so kann er seine Beute behalten und neue Beute kassieren.

Und da liegt mMn das Kernproblem an dieser Art von Spielen, welches bisher soweit ich das gesehen habe noch nicht wirklich gelöst wurde. Den einzigen Mehrwert, den ein fremder Spieler für mich hat, ist seine Beute. Etwas anderes kann er mir nicht bieten, denn die Sicherheit einer festen Gruppe/Gemeinschaft kann ein Fremder zunächst nicht erfüllen. D.h. die einzig sinnvolle umgehensweise mit Fremden ist der Mord, denn das einzige was er mir bieten kann ist Beute. Keines der Spiele hat es mMn bisher geschafft den Spielern einen so großen Anreiz zu geben, andere Spieler nicht zu töten und auf die Beute zum Wohle etwas größeren zu verzichten.

Also um deine Frage zu beantworten, nein, ich spiele kein Rust, ich warte immer noch auf ein Survival das nicht in ein CoD mit Hunger/Durst-Balken ausartet.

Willkommen hier im Forum.

Wie Harlyk schon richtig erkannt hat, kann es so nicht funktionieren, da du die Boolean nach dem Branch setzt und damit das Ergebnis nach dem ersten Tick immer dasselbe sein wird (True).
Ich rate dir stattdessen eine Variable vom Typ Actor zu erstellen, in der das aktuell fokussierte Objekt referenziert wird. Du prüfst dann nach dem Trace ob das aktuell getracete Objekt dem in deiner Variable enspricht. Wenn beide dieselben sind, ist dein Crosshair noch immer auf dem Item und nichts passiert. Wenn sich die Objekte unterscheiden beendest du den Renderer beim alten Objekt, dann erst das neue Objekt in deine Variable und dort den Renderer einschalten. Fertig.

Willkommen im Forum nochmal

Wow was ein Weg. Aber wenns funktioniert passts doch, das ist auf jeden Fall weniger performancelastig

Du kannst in deinen Level Trigger in Form von Boxes oder Spheres einbauen. Dann erstellst du für den Trigger ein Overlapevent das aktiviert wird, sobald du hineinläufst, das nötige Event gibt es schon du musst es nur benutzen (OnActorBeginOverlap). Dort kannst du dann einen Logik für z.B. Scorebildschirm und Levelübergang reinbringen. Wenn du eher einen flüssigen Übergang willst, kannst du stattdessen auch einfach durch Level Streaming (Stichwort zum googlen ) z.B. die Umgebung/Gegnertypen ändern.

Bzgl. des Levelschriftzugs, ich weiß nicht inwieweit man bei dir in verschiedene Richtung gehen kann, Level skippen oder zurück gehen kann, aber Levelübergreifende Infos speicherst du am besten in der Game Instance (wieder was für Google).

Wenn du bei den Highscores etwas planst, was auch über das beenden des Spiels hinaus gespeichert wird oder online gespeichert wird, würde ich mich zunächst mit dem Savesystem von UE auseinandersetzen.

Sehr viel spezifischer kann/will ich nicht werden ohne mehr Infos über die genaue Umsetzung zu kennen, außerdem musst du dich so oder so mit diesen Themen auseinandersetzen und die Richtung und Stichpunkte hast du ja nun erstmal.

Wiegesagt so wie du es jetzt hast könnte es am Ende funktionieren, bedenke aber dass die Performance stark einbrechen wird wenn du sehr viele Mechs hast. Du vergleichst schließlich in jedem Tick alle (!) Mechs und guckst, welche Waffe davon dir gehört bevor du überhaupt irgendwas rotieren kannst. Das mag als hack zum testen OK sein aber ich würde davon abraten das final zu benutzen. Wenn du etwas an deinen Mech dranbaust (Waffen, rotierende tolle Sachen oder sonst was) ist der Weg diese über Sockets an dein Mesh anzuhängen ein relativ simpler und auf jeden Fall performanter.
Naja wie auch immer du es machen willst, schön dass ich bisher helfen konnte.

GetAllActorsOfClass mit Get[0] kannst du natürlich nur benutzen, wenn du dir sicher bist, dass das Array nur aus einem Element besteht, sonst bekommst du eben zufällig eine der Plattformen in der Szene, die sich dann nach deiner Maus dreht. Ich bin mir nicht sicher wie du auf den Parent kommst, da ich das noch nicht so umgesetzt habe, allerdings gibt es bei Widgets die du ineinander verschachtelst eine Variable, die das ParentWidget referenziert, vielleicht gibts bei dir sowas auch.
Es gibt aber vielleicht eine einfachere Methode, und zwar die Waffe/Plattform an einem Socket des Mechskeletons festzumachen. Dann kannst du die Rotation der Waffe direkt in der MechStandartPlayer (deine Oberblueprint halt :)) durch die Socketrotation beeinflussen.

Du kannst doch jederzeit deinen Thread bearbeiten, reicht das denn nicht?

Der Controller hat doch von sich auch schon eine Referenz auf den Player, ControlledPawn.

Entschuldige ich dachte es war klar, dass diese Funktionen unabdinglich sind. Ohne deinen Blueprintgraphen zu sehen ist das halt immer schwierig zu sehen woran man wirklich ist. Aber ist ja gut, dass jetzt wieder ein Problem weniger bei dir da ist.