Pawn sensing wurde schon ewig nicht mehr weiterentwickelt und ist in meinen Augen ein legacy system. Warum Epic das nicht rausgeschmissen hat ist mir ein Rätsel aber offiziell würde man wohl "kompatibilität" sagen.
AI perception ist auch nicht perfekt aber sicherlich die bessere Wahl.
Beide Systeme sind nicht furchtbar performant. Für ein paar Dutzend pawns OK aber wenn tausende pawns herumstreunen gehen beide in die Knie. Da gibt es schönere 3rd party Lösungen.
Versuch mal die betroffenen strucs umzubenennen- dann sollten die refs neu gesetzt werden
OK dann hab ich schon mal etwas falsch verstanden. Das "Core" Paket ist also nur ein "Test". Bei "Core" dachte ich es ist eine zentrale Komponente. Da ist der Name vielleicht etwas unglücklich gewählt. Und dann hast du in der Doku zum Installer in dem Beispiel auch die Abhängigkeit des neuen Plugins auf "Core" gesetzt. Ich würde den "Core" dann eher in "Demo" umbenennen, das hatte mich extrem verwirrt. Bei "Installer" dachte ich es geht nur darum Plugoon selber zu installieren. Das ist beides von der Namensgebung etwas unglücklich. Da entschuldige ich mich dass ich es so missverstanden habe.
Libretro lege ich dir mal ans Herz. Der Fokus ist natürlich ein anderer - Libretro ist ein Emulator Framework. Aber grundsätzlich gibt es Ähnlichkeiten - so gibt es um die Hundert Cores die der Libretro jede Nacht kompiliert und somit immer die neueste Version zur Verfügung stellt - auch wenn das Repository kein Release beinhaltet. Das fand ich persönlich eine sehr gute idee da viele Entwickler weder Lust noch Interesse haben releases überhaupt zur Verfügung zu stellen ("Hier ist die Source, was wollt ihr von mir?") - oder dies definitiv zu selten tun. Dazu ist ein release oft nur für 1 oder 2 Plattformen erstellt.
Die Analogie sind hier die Plugins und die Cores - beides von vielen Entwicklern auf Github bereitgestellte Sourcen die man "einsammeln möchte um sie in einem tool per Klick verfügbar zu machen". Also obwohl es um etwas ganz anderes geht eigentlich der gleiche Gedanke.
Das schöne dabei ist natürlich dass der Buildbot auch für verschiedene Plattformen buildet - also nicht nur für Windows x64.
https://buildbot.libretro.com/nightly/windows/x86_64/latest/
Wie der buildbot funktioniert kannst du hier sehen und ausprobieren (Der aktuelle weicht ein wenig ab aber die Mechanik ist die gleiche):
https://github.com/libretro/libretro-super
Natürlich kannst du machen was du willst. Aber so ein Buildbot würde dafür sorgen dass dein Plugoon eben neuere Versionen bietet als jede andere Quelle und Plattformen die man sonst nicht bekommt (Mal in Bezug auf "Releases"). Sprich das wäre eigentlich DAS Killer Argument warum ich jedem sagen würde "Nimm Plugoon, sonst bist du doof".
Erstmal - schlecht finde ich die Idee nicht. Die Umsetzung finde ich derzeit "etwas dünn" - aber gut du hast ja geschrieben dass es noch nicht fertig ist.
Also hier meine Kritik bzw was mit so aufgefallen ist oder gefehlt hat. Nicht böse gemeint, aber nur "hui wie toll" bringt sich ja auch nicht weiter. Also nehmen oder lassen.
- Erstmal die Source. Es ist nix kommentiert und die paar Kommentare die drin sind wirken als wären sie von woanders übernommen. Es gibt keinerlei Doku zur Source und das ganze ist erst mal super unübersichtlich und vom Naming her unglücklich. A_Core, AC_Core, GI_Core, O_Core, PC_Core. Ich bin mir sicher dass dir die ein-zwei Buchstaben Abkürzungen irgendetwas sagen, aber niemandem sonst fürchte ich. Ja GI ist Game Instance, PC ist der PlayerController usw. Was ich mir hier wünschen würde wäre wenigstens eine Stichworthafte Doku die beschreibt wozu welche Source gut ist.Klar kann man sich durch sämtliche Source files durchhangeln - daran hat aber nicht jeder potentielle Mitstreiter interesse. Und dokumentiere doch durch Kommentare wenigstens grundlegend was du da gerade machst und warum. Mir ist z.B. immer noch nicht klar ob und warum ein System um Plugins runterzuladen einen PlayerCharacter spawnen muss.
- Tags und der Content (Die Plugins) allgemein. Kudos dafür die Icons der Plugins auszulesen - auch wenn gefühlt 90% der open source plugins eh nur die default icons nutzen - Schritt in die richtige Richtung. Die Tags - finde ich so wie sie sind nicht gut. ich würde da eher verpflichtende Properties machen. Die UE Version kann man ja aus der uplugin auslesen, das ist erst mal das wichtigste property und sollte sicherlich kein optionales Tag sein. Wenn ich 4.27.2 nutze will ich ja kein UE5 plugin runterladen und so. Dann vermisse ich die Unterscheidung "Engine vs. Project" plugin bzw "hybrid". Grundsätzlich sollte auch erkenntlich sein ob es "Editor oder Runtime" (Oder beides) ist. Auch recht wichtig "Rein Blueprint", "Rein C++" oder "Hybrid". Eine sinnige Kategorisierung ist schwierig da plugins ja grundsätzlich alles enthalten können was nur denkbar ist, aber ich denke man sollte es wenigstens versuchen.
- Account. Mit dem Account erstellen ist nachvollziehbar aber es lässt so einen bitteren Beigeschmack a la "Wird das mal was kosten?", "Will der irgendwann Werbung machen?", "ist das überhaupt neutral"?
- Von anderen lernen. Ich habe viel Respekt für libretro. Die haben einen richtig guten buildbot der jede nacht die Sourcen selber buildet. Klar kann man sich zurücklehnen und auf releases hoffen und dass irgendwer die einträgt aber ich glaube da kann man sich das eine oder andere abschauen.
Kannst das log ja mal hochladen dann werf ich bei Gelegenheit mal nen Blick drauf
Puh! Ja wie gut dass du das Log hochgeladen hast. Das Ding strotzt ja nur so vor Fehlern. Was natürlich ins AUge fällt sind die tausenden "Texture stream in request failed due to IO error". Ich muss gestehen das habe ich noch nie gesehen. Google mal nach der Meldung in ANführungszeichen - null Ergebnisse. Ist also wirklich nix gebräuchliches.
Ich sammel mal hier meine Gedanken aus dem Log:
- LogLuminAPIImpl Fehler. Sieht für mich aus als würdest du versuchen ein magicLeap Plugin zu verwenden. Das fällt schon beim Laden auf die Fresse.
- PixWinPlugin Fehler. Auch das Ding fällt auf die Fresse.
- OpenXR Fehler - wenn du OpenXR nicht nutzt würde ich es deaktivieren.
- SIeht aus als wenn du AutoSettings als Plugin benutzt - es meckert aber dass etliche Variablen nicht gesetzt sind wie z.B. GameAudio.MasterVolume usw.
- Dann startet das Spiel wo du ein UIOnly setzt aber ein Widget hast das gar nicht fokusierbar ist (Oder kein Widget?)
- Jetzt lädt die Map MinerWorld und begrüßt uns damit dass 4 BP_PREY_RAT nicht gespawnt werden wg collission
- DIe Meldung mit Object None.None - kann ich nur raten, vielleicht versuchst du auf was nicht vorhandenes zu referenzieren, evtl die PREY_RAT?
- Jetzt fängt das ganze Elend an. Also IronPick - das Material scheint das ganze Elend zu provozieren. Hier kommen jetzt die ganzen tausenden Fehler. Ich hab das Project nicht vor mir, aber das Material könnte im Sack sein, die texturen werden nicht geladen. Eventuell sind die texturen irgendwie inkompatibel? ich würde das material löschen, die texturen löschen und das ganze vosichtshalber alle mit neuem namen neu erstellen. Hier ist irgendwas total faul!!!!!
- Display: Temp texture streaming buffer not large enough, needed 8388608 bytes. Das ist schon schlecht aber ich habe hier auch erst mal die IronPick in Verdacht, da läuft irgendwas wirklich nicht rund.
- EIne Niagara component beginnt zu straucheln - aber auch hier mache ich erst mal den Buffer für Verantwortlich
- Game/GUI/widgets/templates/items/Upgrade_Stones.Upgrade_Stones_C:GetPercent_1 - hier versuchst du durch null zu teilen (In unserer zugegeben schlechten Situation). Niemals durch null teilen! Frage vorher ab ob der Wert durch den du hier teilen willst null ist und wenn ja dann lass es mit dem teilen.
- Jetzt kommen noch tausende Teilungen durch Null und Probleme mit dem IronPick. Irgendwann läuft dann wohl irgendein buffer vollends zu.
Mein Fazit: IronPick. Das Material. Verbrenne es feierlich mitsamt seinen texturen. mache es neu. Schau dir die texturen ganz genau an. Irgendwas ist da krumm. Teile nicht durch null - verbesser deine StonesGetPercent. Fixe die anderen Fehler. Ist nicht verboten Plugins zu laden obwohl man sie nicht verwendet aber wenn sie Fehler schmeissen dann sollte man über eine Trennung nachdenken. gelegntlich mal ins Log schauen und versuchen Fehler und Warnungen zu beseitigen - auch wenn sie nicht kritisch sind.
Lad doch mal das ganze log hoch und ich schau mal ob ich was sehe
Dann benenn die doch nach dem built um. Das hat ja nun nix mit dem project zu tun.
Ich würde ein Projekt gar nicht umbenennen. Zumindest wenn C++ drin ist ist es teilweise sehr aufwändig alles anzupassen. Da würde ich dann schon eher ein neues Projekt erstellen und dann den Inhalt da rein migrieren. Was noch dazu kommt - der Projektname ist total egal, ich sehe nicht warum man überhaupt Zeit dafür aufwänden sollte.
Ich hatte so krasse Probleme mit UE5 - es ist abgestürzt bevor der Editor überhaupt aufging. Anhand des Crash logs habe ich dann das MegaScans krams (bridge und plugin) aus dem UE4 engine Verzeichnis gelöscht, danach lief es. Schau doch mal ins log nach Absturz.
OK dass was du gemacht hast nicht gut ist hast du ja schon gemerkt. Der Projektname ist grundsätzlich auch immer der Namespace. Du merkst worauf ich hinaus will. Wenn du vorhast Experimente zu machen dann sicher vorher wenigstens das project folder.
Was mir so ins Auge sticht ist dass hier laut deinem Log "UE4Game.target" nicht gefunden wird. Von daher hiess dein Projekt wohl mal "UE4Game". Dann sehe ich weiter er ruft "Game.Target.cs". Also heisst dein Projekt jetzt aktuell "Game" nehme ich an?
Vielleicht irre ich mich - aus dem kurzen Log kann ich nicht komplett ersehen was du wann und wie umbenannt hast - aber es scheint als hättest du dabei echt ins klo gegriffen. Das Ding liegt ja in deinem Download Ordner - wenn du den download noch hast schau dir doch mal an wie es ursprünglich hiess.
Da der Rendering thread abstürzt würde ich generell erst mal checken ob du den neuesten Grafikkartentreiber installiert hast.
Natürlich kann sowas auch ein Logikfehler im Spiel sein, zum Beispiel auf eine Kamera wechseln die gar nicht verfügbar ist oder VR FUnktionen nutzen die gerade nicht verfügbar sind usw.
Habe gerade mal den night Mode angemacht - oh mann was sehen die Rückleuchten geil aus mit Lumen und so. Schade dass DLSS noch nicht fertig ist für UE5, aber kommt wahrscheinlich die nächsten tage. Teils ist die big City map auch auf ner 2080 Super in FHD etwas träge. Aber grundsätzlich macht es Spass so ein AAA Ding aufm heimischen Rechner als Source zu haben.
Was wäre denn Thema? Ich habe ja in letzter zeit versucht mich in C++ und Thema Blueprint enabled plugins einzuarbeiten weil ich das für eine sinnvolle Erweiterung der Engine halte. Da könnte die Community von profitieren. Oder auch ein thema was hier bisher glaube ich nie ankam - sounds in UE4. Von Steam Audio über Quartz subsystem gäbe es da ja auch viel zu tun. Post Process wäre ja auch ein tolles Thema, es gibt so viele geile Effekte die man machen könnte.
Auch wenn ich da wahrscheinlich allein bin war mein erster Gedanke "Oh Gott lass es keinen 3D modeling Wettbewerb sein".
Wieder mal etwas sehr spezielles, also nicht sicher ob es für jemanden brauchbar ist. Ich hatte es aber für ein privates Projekt gebraucht und die Lösung ist sehr einfach. Ich habe einen Faktor für die Bild-Entsättigung eingebaut, damit kann man auch schöne CGA-alike Grenzfarben (RGB) hinbekommen. Für mich reicht aber Schwarz Weiss.
Vielleicht kanns ja jemand gebrauchen...
Download:
Das mit den Shadern hat bei UE4 schon sehr genervt und bei UE5 hat man dieses nervige Feature beibehalten. Danke! Warum UE die scheiss Shader nicht einfach irgendwo speichert sondern sie immer und immer wieder neu kompiliert erschliesst sich mir nicht. Zumindest die aus der Engine sollten irgendwo gespeichert werden, bei einem leeren Projekt tausende Shaders die ich überhaupt nicht verwende immer und immer wieder zu kompilieren ist lächerlich.
Übrigens - falls jemand den Colored Smoke builden will - Alembic Groom importer Plugin rein, danach geht auch kompilieren. Niagara Fluids braucht sowohl den Groom als auch den Alembic Groom importer. Fragt mich jetzt nicht was Groom mit Rauch zu tun hat... Und schön dass die Abhängigkeiten nicht einprogrammiert sind...
Nettes Plugin um ein scene Capture in einem separaten Fenster abzuspielen. Also wieder mal eher was für Leute die mehrere Monitore nutzen...So könnte man z.B. Rückspiegel oder Seitenscheibe eines Autos auf einem anderen Bildschirm darstellen.
Ich habe es mal auf 4.27 portiert weil ich damit etwas gespielt habe.
Original hier:
Und hier meine 4.27er Version. Vielleicht kanns jemand gebrauchen.
https://drive.google.com/file/d/1tkA_b8dQkZ9idEcBcwUNG1VOVIo7ttnc/view?usp=share_link
