Alles anzeigenjetzt nach dem Neustart hat er alles ohne Errors gemacht, bleibt aber noch mein Problem nichts bewegen zu können...
wenn ich die Pfeile benutze dann Passiert nichts.
Aber damit geht es
und das stört mich, vorher ging es ja auch und so ist das einfach nur Nervig.
Okay, dabei bin ich leider auch überfragt.
Da scheint ein Prozess doppelt zu laufen.
Du müsstest im Taskmanager irgendwas sehen was da rumwerkelt.
Wenn du aber auf Nummer sicher gehen willst starte eben den Rechner neu und versuch es nochmal.
Der findet die .Net Libraries bei dir nicht. Check nochmal den Visual studio installer und guck ob die drin sind.
Oh sorry Zwischenschritt vergessen, falls du noch keine .sln hast einfach eine generieren und dann doppelklick drauf:
Hey,
Starte mal den Visual Studio Installer 2022 und stell sicher, dass dein VS aktuell ist.
2. Spieleentwicklung aktivieren
3. Altes .Net 3.1 Paket Installieren (Das kommt bei VS2022 nicht mehr automatisch mit)
Danach versuchst du dein Projekt aus VS2022 neu zu builden:
4. Projekt.sln mit VS öffnen und
5. Auf Rebuild Solution gehen:
Mit etwas glück rennt der dir durch. Falls nicht kriegst du in der Konsole ein Error Log, was du uns schicken kannst.
Gruss Veelos
Hallo Leute,
Ich habe noch ein kleine Update gemacht.
Bei dem Anlegen von einem eigenen Plugin können jetzt mehr Informationen gespeichert werden:
Diese Verlinkungen werden dann im Store angezeigt sofern diese ausgefüllt wurden:
Weiterhin habe ich direkt im Installer eine Feedback Funktion eingebaut damit Ihr nicht mal mehr den Unreal Editor verlassen müsst um mich anmeckern zu können 
Weiterhin habe ich einen Bug gefixt, der die Leute automatisch nach einer Stunde aus geloggt hat.
In der neusten Version :
https://github.com/Plugoon/Plu…ses/tag/UE5.0-v1.1.1-beta
wurde auch eine gepackte Version des Plugins mit hochgeladen, damit es nicht mehr notwendig ist das Plugin über C++ selber zu kompilieren. (Der Installer kann jetzt auch in reinen Blueprint Projekten verwendet werden)
An dieser Stelle ein kleiner Hinweis. Ein gepacktes Plugin verfügt über lustige Binary Dateien. Auf diese reagiert jedes halbwegs anständige Virenprogramm und auch Windows sehr allergisch sofern diese nicht aus einer Bekannten Quelle stammen.
Mein GitHub Repository ist keine bekannte Quelle. Deshalb nicht wundern, wenn das Virenprogramm anschlägt.
Später werde ich den Installer über den Unreal Marketplace zur Verfügung stellen (ich weiss ironisch 
) . Bei Epic handelt es sich um eine bekannte Quelle und dann sollte das Virenprogramm auch nicht mehr anschlagen.
Gruss Veelos
Ich nehme mal an du beziehst dich bei dem Exception Handling auf C++?
Das kannst du aktivieren:
Quelle:
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.
Achsoo jetzt weiss ich was du meinst. Grundlegen den CI/CD Prozess von der Entwickler Seite auf den Installer auszulagern?
Ich Kategorisiere das mal als Feature Request für die Zukunft.
Das Problem in meiner aktuellen Lage hast du hier selber ganz gut beschrieben "von vielen Entwicklern...". Die Kosten die für sowas Anfallen (Build Prozesse müssten ja irgendwo laufen) kann ich aktuell nicht tragen.
Ich mache das Projekt aktuell alleine und verfüge leider nicht über die Ressourcen um sowas im aktuellen Stand auch nur in Erwägung zu ziehen.
Alternativ kann ich mir aber mal die Building Pipelines von GitHub genauer ansehen und diese als Template zur Verfügung stellen.
Btw, das wäre bereits jetzt für jeden der Plugoon nutzen möchte theoretisch möglich, wenn man sich mit Github Pipelines auskennt. Ich könnte dann auch die API so erweitern, dass ein automatisches hinzufügen von deployten Packages möglich wäre.
Soll heissen -> automatisches deployment auf Plugoon, sobald der Entwickler am Source etwas ändert. (Sofern der Entwickler bei sich die Pipelines eingerichtet hat)
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.
Keine Sorge ich nehme niemandem seine Kritik krum. Immerhin habe ich danach gefragt. Trotzdem habe ich noch ein paar Fragen zu einigen Punkten.
- 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.
Ich glaube hier steht ein Missverständnis im Raum. Ich entwickle aktuell ausschliesslich an dem Paket Manager. Keine Inhalte. Das Plugoon.Core ist aus Testgründen drin. Hat aber mit dem Installer wenig zu tun. Plugins die ich später für diesen Installer erstelle werden natürlich entsprechend Kommentiert sein. Mir geht es aber aktuell ausschliesslich um den Paket Manager selber.
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.
Bei dem Versionstag verwechselst du etwas. Die Version steht für die Plugin Version. Der Paket Manager zeigt dir ausschliesslich Versionen an, die mit deiner aktuellen verwendeten Engine Version kompatibel sind. Pakete für andere Versionen werden Präventiv gefiltert.
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.
Bin ich absolut deiner Meinung. Ist in Planung und kommt noch. Mir ging es darum mit dem Installer so schnell wie möglich (mit dem MVP) an die Community zu treten um so schnell wie möglich Feedback rein zu kriegen. Deshalb fehlen noch viele Features. Feedbacks wie deines helfen mir aber dabei die Zukünftigen Features zu priorisieren.
- 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"?
Verständlich. Zukünftig möchte ich das reine Runterladen und installieren von Plugins ohne Anmeldung möglich machen. Die Anmeldung wird nur dann notwendig wenn man eigene Plugins verwaltet (Die muss ich ja irgend einer Identität zuweisen).
Ich habe in nicht vor die Accounts für etwas anderes als Identity Management zu verwenden. Deshalb betone ich hier nochmals: (Wenn jemand seinen Account gelöscht haben möchte, werde ich das sofort tun).
Der Grund warum ich mich in der frühen Testphase für einen Account Zwang entschieden habe ist um mich vor ungewünschten Anfragen aus Asien zu schützen. Bei einer öffentlichen API kommt dies häufiger vor und das würde meiner Brieftasche etwas weh tun.
- 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.
Libretro sagt mir ehrlich gesagt nichts und ich sehe keine direkte Verbindung zu einem Paket Manager? Vielleicht stehe ich auf dem schlauch.
Der Paket Manager ist ausschliesslich dazu gedacht, dass Leute ihre Plugins auf einfache art und weise der Community zur Verfügung stellen können. Ähnlich dem Node Package Manager, dem .NET Framework oder der Python Library.
Mir ist z.B. immer noch nicht klar ob und warum ein System um Plugins runterzuladen einen PlayerCharacter spawnen muss.
Damit hast du mich richtig verwirrt. Das System muss keinen PlayerCharacter spawnen? Wie kommst du darauf?
Jedenfalls Danke für dein Feedback und ich hoffe du kannst mir meine offenen Fragen beantworten.
Gruss Veelos
Hey Leute,
Ich bin ma wieder hier um ein kleines Projekt von mir Vorzustellen.
Bei Plugoon handelt es sich um einen Unreal Package Manager. Dabei habe ich mich von gängigen Paket Managern wie NPM oder dem Unity Packet Manager inspirieren lassen.
Die aktuellen Features beinhalten einen Plugin Store über den Plugins runter geladen werden können. (Der ist aktuell noch ziemlich leer aber ich habe vor das in den nächsten Monaten zu ändern.)
und die Möglichkeit eigene Plugins in den Store zu stellen. Die Plugins können Abhängigkeiten zu anderen Plugins beinhalten. Ist dies der Fall werden die Abhängigkeiten automatisch bei der Installation mit installiert.
Der Grund warum ich dieses Projekt umgesetzt habe war, dass ich privat in meinen Projekten sehr gerne Modular arbeite. Dabei habe ich aber regelmässig den Überblick über all meine Module und Abhängigkeiten verloren.
Plugoon befindet sich aktuell noch in einer Test Version. Das heisst einige Dinge funktionieren noch etwas suboptimal:
- Das UI funktioniert aktuell noch nicht asynchron (friert ein bei Anfragen an den Server)
- Plugin Icons werden noch nicht sauber aus dem Repository geladen
um nur einige Dinge zu nennen.
Zukünftig habe ich vor noch weiter Features wie zum Beispiel privaten Repository Support hinzu zu fügen.
Auch wenn der Installer noch nicht ganz fertig ist, wollte ich ihn hier schonmal vorstellen um erste Feedbacks zu kriegen.
Ihr könnt den Installer hier herunter laden:
https://github.com/Plugoon/PlugoonInstaller/releases
Hier findet ihr eine Wiki Seite die bei der Installation hilft.
https://github.com/Plugoon/PlugoonInstaller/wiki
In der Testphase ist es noch notwendig einen Account zu erstellen um auf den Installer zuzugreifen. Dies ist einfach eine zusätzliche Massnahme um das Backend vor ungewünschten Requests zu schützen.
Selbstredend werden die E-Mail Adressen nicht an dritte weiter gegeben und auf Anfrage (PN hier im Forum) werde ich die Accounts entfernen.
Um den Installer zukünftig zu verbessern habe ich hier eine Umfrage erstellt. Bitte füllt diese aus 
https://docs.google.com/forms/…Oyow8aeIX0fEJ1gPisDg/edit
Ich lade euch gerne dazu ein den Installer herunter zu laden, zu testen und auch eigene Plugins in dem Store hinzu zu fügen (Anleitung hierzu findet Ihr im Wiki)
Für Fragen oder Anmerkungen stehe ich gerne zur Verfügung.
Gruss Veelos
Das was du suchst geht in die Richtung Graphen Theorie.
Ich gehe mal davon aus, dass jedes Modul ein eigener Actor ist? (Muss es aber nicht sein)
Du stellst jedes Modul beim Aufbau als "Knoten" dar und verbindest seine Nachbarmodule über "Kanten". Dadurch baust du nach und nach einen Graphen auf
Wird nun ein Modul zerstörst löst du in jedem zb den Shortest Path Algorithmus zum Grundstein aus:
Findet ein Modul keinen Pfad mehr, dann ist es nicht mehr mit dem Grundstein verbunden.
Gruss Veelos
Ergänzung zu Geloscht :
Das liegt nicht am Tree sondern am Navmesh. Wenn er das nicht im Current Level findet kann sich die AI nicht bewegen.
Fatal error: [File:D:/Build/++UE4/Sync/Engine/Source/Runtime/Windows/D3D11RHI/Private/D3D11Util.cpp] [Line: 198] Unreal Engine is exiting due to D3D device being lost. (Error: 0x887A0020 - 'INTERNAL_ERROR')
Kann jetzt sein, dass ich was komplett falsch verstanden habe, aber könnte es sein, dass er die Verbindung zu der D: Festplatte kurzfristig verliert und Unreal dann nicht auf die Files zugreifen kann?
Fazit: -> Unreal und Projekt auf die C: Platte packen, wenns dann funktioniert hab ich recht, sonst weiter suchen?:D
Gruss Veelos
Caste mal auf den Gamemode die du haben willst. Ich glaube das geht.
Nein das klappt nicht. Du kannst nur zu etwas casten was in der vererbungs-Hierarchie der Klasse vorkommt. Sonst wird dein cast immer fehlschlagen.
Zu der eigentlichen Frage:
Meines Wissens nach ist der GameMode fix an das geladene Level gekoppelt. Den kannst du zur Runtime nur wechseln, wenn du das Level wechselst.
Deine Logik müsste also wo anders hin. Eventuelle auf den Player State, Player Controller oder Character.
Angenommen jemand ist voll von meinem Projekt überzeugt, wie kriege ich Ihn dazu alles niederzulegen und vollzeit bei mir mitzuarbeiten?
Ich komme mal auf die Ursprüngliche Frage zurück.
Meinst du mit "Vollzeit", dass jemand seinen bezahlten Job hinschmeisst und seine komplette Zeit in dein Projekt investiert?
Dann ist die Antwort ziemlich klar: Geld.
Wenn es nur darum geht in der Woche einige Stunden zu investieren, dann fallen mir drei Punkte ein, die mich überzeugen könnten.
1. Mehr Geld 
2. Ich finde eine Projektidee so genial, dass ich daran unbedingt mitarbeiten will
3. Ein "alter Hase" ist mit dabei, der mir einiges beibringen kann, was ich noch nicht kenne
Wenn du nichts von dem bieten / verraten kannst, dann sehe ich da ehrlich gesagt schwarz.
Gruss Veelos
Klar, das eine Engine möglicherweise den Multiplayer einfacher zur Verfügung stellt möchte ich gar nicht beurteilen (dafür wüsste ich auch zu wenig darüber). Was ich weiß ist, dass es trotzdem sehr viele Leute gibt, die auch mit Unity einen wunderbaren Multiplayer zaubern. Die benutzen nur halt ihre Mittel, die ihnen von Unity zu verfügung gestellt werden am Besten. Wenn ich natürlich frisch von Unreal komme mit der Einstellung, dass da schon ein MultiplayerSystem-Template oder ähnliches auf mich wartet, dann werde ich enttäuscht.
Was ich damit nur sagen möchte ist, dass erfahrene Unity-Nutzer auch den Multiplayer letzendlich implementieren können, weil sie die Engine spezifischen Features besser kennen als Unreal-Nutzer. Möglicherweise findet der Unity-Nutzer das Multiplayer-System von Unreal besser, aber weiß, dass seine Erfahrung in Unity einfach gold wert ist und eine Umgewöhnung auf einen anderen Workflow dafür einfach zu viel Zeit frisst.
Versteh mich bitte nicht falsch. Ich habe nie Behauptet, dass Multiplayer in Unity nicht möglich sei. Soweit ich es beurteilen kann sind die MP Ansätze in Unity aktuell aber zu einem Grossteil Custom.
Das muss per se auch nichts schlechtes sein. Je nach Use Case könnte es zum Beispiel sein, dass du extrem auf deine Bandbreite achten musst und deshalb auf eine eigene Umsetzung der Replikation setzen musst. In so einem Fall würde ich Unity sogar bevorzugen, da es für mich einfacher iwelche Custom Replication in Unity einzubauen als mich in das Subsystem Interface von Unreal einzuarbeiten.
Möchte ich aber das Standard Steam Coop Erlebnis setze ich auf Unreal und das drag & drop klicki bunti.
Tatsächlich habe ich bis auf wenige Dinge (Wie zb, dass es Unity scheinbar nicht hin bekommt halbwegs stabile Builds raus zu hauen) nichts gegen Unity einzuwenden. Ich habe mit beidem gearbeitet und je nach Use Case wechsle ich zwischen Unity, Unreal oder auch anderen Engines wie Godot hin und her. Im Grundsatz funktionieren die nämlich alle gleich .
Der Rest ist persönliche Präferenz.
Gäbe es einen Unreal Bashing Thread könnte ich da auch das eine oder andere dazu erzählen 
.
Nein eben nicht da sowohl das Finanzamt also auch das Geld von deinem Bruttoumsatz haben möchte.
Du bezahlst nicht erst Epic Games und das Finanzamt holt sich dann das Geld aus dem was übrig bleibt.
Habe nie was anders behauptet, trotzdem will Epic nicht 5% von deinem Brutto Umsatz sondern 5% von deinem Brutto Umsatz - 1Mio.
Im Klartext: Du zahlst Steuern von 1,1 Millionen und dann möchte Epic Games die 5% ebenfalls von 1,1 Millionen. Das heißt die 5% von 1,1 Millionen werden zwar aus deinem Brutto berechnet gehen aber von deinem Netto weg.
Das ist ja aber eben nicht der Fall. Epic möchte die 5% von (1.1 Mio - 1Mio), was dann 5k entspricht. Das die dann von deinem Netto weg gehen ist klar.
Meine Meinung dazu: Da wir hier ein Unreal Forum sind, ist es doch ein wenig kontraproduktiv über eine andere Software zu bashen wenn kaum Leute der Gegenseite da sind ?
Warum denn? Klar wäre es besser, wenn die Gegenseite Ihre Argumente direkt mit uns Diskutieren könnte. Allerdings bin ich ziemlich sicher, dass das Thema auch bei den Unity Foren Diskutiert wird.
Wenn ich mir jetzt ein Bild machen möchte, welche Engine ich für mich benutzen möchte, würde ich genau nach solchen Beiträgen in beiden Foren suchen und dann für mich abwägen.
Bashen ist vielleicht etwas fies gesagt aber ich glaube ich war bei meinem Beitrag noch relativ fair
