Wozu brauchst du denn ein Child, du kannst BP actors doch so oft spawnen wie du willst?
Hmmm ich glaube ich verstehe es ein bisschen - ist schwierig ohne deinen Blueprint zu sehen - so kann ich nur raten, da ich den code nicht sehen kann und nur eine vage Vorstellung habe was dein BP überhaupt macht. Meiner Meinung nach eignet sich ein prozeduraler BP nur bedingt im Editor weil du ja zur Laufzeit sehr einfach über Funktionen a la "ist zu meiner rechten noch ein Raum" aufrufen kannst - im Editor bist du da aber sehr beschränkt. Wenn es WIRKLICH prozedural geschehen soll - dann macht das ja auch nur zur Laufzeit wirklich Sinn - im Gedanken daß jeder Spieler ein zufällig generiertes Haus mit X Räumen haben soll - jedes verschieden.
Aber wie gesagt - ohne den BP vor mir zu haben bin ich hier mehr am raten als alles andere.
Danke für den Hinweis 
Ich hab auf jedenfall schon herausgefunden dass der child actor component total verbuggt ist.
Eine Alternative wäre von Vorteil oder irgend eine andere herangehensweise die mir nicht in den Sinn gekommen ist um random Räume aneinander zu setzen.
Wenn ich vor hätte, das irgendwann mal aufzubauen, würd ich Sockets abfragen und dann nen neuen Actor spawnen, der wieder Sockets abfragt^^
dass der child actor component total verbuggt ist.
Mit nem "Child Actor" hab ich noch nie was gemacht...
Edit: Mir hat das irgendwie keine Ruhe gelassen, musste es jetzt einfach mal testen:
Mit ein paar Regeln könnte man da bestimmt ordentlich was draus machen.
Wobei ich sagen muss, dass das so schon besser klappt als ich mir vorgestellt hatte, nach grad mal 1std Arbeit (wobei die Meshes wohl am längsten brauchten)^^
Es wird nur abgefragt, ob an der Position eines Sockets schon ein Raum vorhanden ist und wenn ja, wird nichts weiter gemacht.
Außerdem gibts ne 10% Chance, dass zufällig statt nem Raum, ne Wand entsteht.
Wenn das (eingestellte) Maximum an Räumen erreicht ist, wird überall ne Wand gesetzt^^
Sehr schönes Vid.
Das hatte ich aus erst.
Danke^^
Und wieso nicht mehr?
Jedoch kann ich ja nur im Editor nicht spawnen, leider.
Wieso willst du es unbedingt im Editor und nicht "at Runtime" umsetzen?
Wenn es darum geht, dass man die Räume auch noch dekorieren muss und Enemy-Spawner setzen, dann kann man das ganze auch genauso "at Runtime" automatisch machen, statt aber einfach bei allen Sockets nen Test laufen zu lassen ob ein Raum platziert werden kann, müsste man dann die Sockets umbenennen, in z.B. Room_Socket, Plant_Socket, Light_Socket, usw. und dann lässt man checken, welcher Typ von Socket grad getestet wird^^
Theoretisch könnte es auch im Editor funzen, wenn man statt einem neuen Actor zu spawnen, das ganze über Hierarchical Meshs laufen lässt, wobei das ne Menge Mehraufwand ist und ich grad nicht mal weiß, ob das überhaupt klappt, wie ich es mir denke...
Mein System klappt, also hab ich keinen Grund es zu ändern, nur noch zu erweitern^^
oder ich mach es mit C++. Wollte eig. nur mit BP hinbekommen.
Wenn man schon C++ beherrscht (nicht nur "kann"), kann man natürlich C++ verwenden, jedoch sollte keiner nur weil er gerade in diesem Moment nicht weiter kommt, denken, dass er jetzt unbedingt C++ lernen muss, denn da werden sich auch noch einige Probleme ergeben, an die man in diesem Augenblick gar nicht denkt.
Besser wäre es, wenn man sich mehr in die BPs einarbeitet, das kostet höchstwahrscheinlich weniger Zeit und man lernt noch was dazu, was man auch in anderen Bereichen benutzen kann.
Bei C++ lernt man zwar auch was, aber da fängt man eben wieder bei 0 an und am Ende stellt sich immer die Frage, ob man das gelernte jetzt auch in anderen Bereichen umsetzen kann und vor allem ob es schneller ging, als mit BPs.
Als ich anfing, Spiele zu entwickeln, hab ich mir gesagt, dass ich meine Spiele niemals per C++ umsetzen werde, ich werde alles dafür tun, dass alles per BP möglich ist und bisher war es das auch.
Anfangs hatte ich noch einige Probleme, aber inzwischen stell ich mir was vor, probiere es aus und es klappt meistens sofort, selbst wenn ich sowas noch nie gemacht hab (wie man im Video sieht)...
Dabei arbeite ich erst seit 3 Jahren mit der UE4 als Programmierer, davor hab ich immer nur Level-Design gemacht (von HTML mal abgesehen)^^
Theoretisch könnte es auch im Editor funzen, wenn man statt einem neuen Actor zu spawnen, das ganze über Hierarchical Meshs laufen lässt, wobei das ne Menge Mehraufwand ist und ich grad nicht mal weiß, ob das überhaupt klappt, wie ich es mir denke...
Also mein System ist auf HISMs aufgebaut. Falls ichdich richtig verstehe.
Als ich anfing, Spiele zu entwickeln, hab ich mir gesagt, dass ich meine Spiele niemals per C++ umsetzen werde, ich werde alles dafür tun, dass alles per BP möglich ist und bisher war es das auch.
Das hatte ich auch mir am Anfang so gedacht und versuche es auch bisher auch so umzusetzen. Leider kommt man an einen Punkt wo man dann nicht weiterkommt. Und ab da will man ja ungern sein bisher erreichtes verwerfen und mit einem anderen Ansatz rangehen.
Vllt muss ich mir mein Script anders aufbauen als gedacht. Manchmal ist einfach nicht besser 
Hey zusammen
Beim Procedural Runtime Generieren haben die Designer einfach wenig bis keine Kontrolle wie die Map nachher aussieht,
denn nach der Session sind die Objekte ja weg entsprechend muss dann alles zur Laufzeit generiert werden.
Wenn man das im Editor macht, hat man jedoch beides, das Grundlevel Procedural und danach manuell verfeinern. Das Level sieht dann aber immer gleich aus, es macht das erstellen einfach schneller.
Die Objekte werden da einfach beim Construct schon generiert. Wenn ich Druusch richtig verstanden habe, klappt das ja auch,
nur die Platzierung scheint das Problem zu sein, da ist wohl irgendwo ein Fehler drin.
Mit so wenig Informationen kann man aber kaum raten.
Die Idee mit HISM verstehe ich nicht, einerseits sind ChildActors nötig und dann reicht doch HISM, wenn das reicht,
wozu die Child Actors?
Hier ein Beispiel von mir mit Random Generierten ChildActors im Editor, das coole daran ist, man kann so oft Generieren bis es passt und danach einfach alles bewegen bis es am richtigen Ort ist. Wenn man viele Level erstellen muss geht das auch viel schneller.
Das war meine Intention. Prozedural generieren und dann editieren.
Ok, ich dachte es sollen prozedural generierte Level werden und nicht nur im Editor^^
war von mir leider nicht richtig ausgedrückt. Ich gelobe Besserung 
Damit das als ein "Konstrukt" angesehen wird gibt es mehrere Möglichkeiten. Bleiben wir einmal bei BP, als da wären unter Anderem die ChildActorComponents, dann einfach StaticMeshComponents und HISM die du nutzt.
Generieren wir mal Objekte mit allein drei Optionen, zuerst spawme ich die Cubes mit HISM, dann mit ChildActorComponents, und zuletzt noch mit StaticMeshComponents.
Das sieht alles gleich aus, oder?
Im Grunde ist der Prozess ja bei allen sehr ähnlich, aussehen tun diese auch gleich.
Der Unterschied ist vor allem die Performance und die jeweiligen Möglichkeiten.
HISM performt am besten weil es sich um Instanzen handelt, dafür sind die Möglichkeiten eingeschränkt. Glücklicherweise muss eine Wand in der Regel auch nicht viel mehr tun als Wand sein. Schwieriger wirds bei Gameplay Elementen.1
Du siehst auch, dass LODs unabhängig bei allen funktioniert.
Gruss