@dkoding I’ve found the root cause of the scaling issue. However it requires a lot of testing, I’ll get it done over the weekend. I’ll have a look at your physics crash issue tomorrow
This is a much requested feature. I’ll explore ways to add this in the grid builder over the weekend
What about Snap builder ? (since I am working with multi-story/floor dungeon)
@, The usual modular art guidelines apply and DA would adapt to it. The pivot and grid size can be adjusted from within the theme editor. Having your wall pillars not baked into the wall meshes would help as they can be added separately from the theme editor
Sorry, I meant the long corridor selector / emitter example.
@DrinkThisPotion I’ll have that by tomorrow. In the mean time, I’ll need more info. How would you like to have the result? What do you intend to do with the resulting corridor?
I would like to theme override the corridor and corridor padding between rooms, so I can create different themes for different corridors rather than just one section of a corridor.
–
Separately for another design, I need to find a way in rooms to emit a marker paths between each door so I can build bridges between doors and not have a floor. Currently I couldn’t figure out a way to do this.
Hi [MENTION=28980][/MENTION], I’m having an issue with the point light node, it places the lights as it should but when I try to bake lighting for the dungeon I get the following error:
MapCheck:Warning: Warning PointLight_257 ‘PointLight_257’ has same light GUID as ‘PointLight_140’ (Duplicate and replace the orig with the new one)
I get this for every single light in the scene which seems like it’s preventing the proper bake of lighting coming from these lights.
@Ratamorph Thanks for the bug report. I’ve fixed the issue and it will be available in the next update
Clustered Theming
Automatically apply different themes to various parts of your dungeon using the new clustered theming feature
It groups all connected corridors together into clusters. The room and corridor clusters are then applied different themes automatically without having to deal with volumes
This will help in adding variation to your level. The following level uses 3 different themes
I’ll create a more beautiful example with the Hell Forge demo
You do this by enabling clustered theming from the configuration
Then assign the themes you’d like to add on various clusters.
is how the clusters are created (debug data, each color is a cluster)
Height variations will also be taking into consideration as long as it is able to reach it (though a stair). It can also be turned of (notice lower right corridor)
The system is generic enough to allow different builders to also use this feature. For now, only the grid builder uses it
Hi , I really appreciate the viral and horde-forming mechanics in Zombie City. In my opinion, one of the most effect uses for Zombies, I wish more Zombie games would take advantage of the Viral mechanic.
City Builder is looking really nice. Atter viewing the Zombie City, I can definitely imagine putting City Builder to use in developing a Alien Invasion Survival/Crafting Game concept I’ve been stewing over. Keep up the work!
Thanks, Looks good! I am still on DA 2.2.0 since some of the bugs mentioned in later updates worried me and I have built a lot around the query feature. The clustering feature removing the need for volumes would be nice, making it less level dependent for a runtime project and giving the ability to override whole corridors, which is exactly what has been a struggle 
Hey, a quick feature request, it would be nice to be able to drag static meshes and actors from the Content Browser and drop them into the graph of a Dungeon Theme, automatically creating the proper Mesh or Actor node. This would make the workflow for creating a new theme much quicker!
EDIT: Found a bug. If an Actor has a Child Actor Component and you increase the Cell Size of your dungeon, the Child Actor’s positions do not update.
Nice to have more control over themes and the avoidance of too many themereplacementvolumes scattered all over the level is a nice addition, too.
Will be really handy if used in conjunction with the “gameflow” editor on which you work. Entrance, exit, bossroom or library with clustered theme control will be great.
Studying the screenshot of your debug dungeon I found some problematic areas in the layout. Stairs that are at room borders are not only visually very ugly but can break
gameplay as unreachable areas where doors meets stairs could be generated.
Is it possible to limit heightvariations to corridors and suppress them near rooms? I really like having heightvariations in the random levels but it’s problematic without control.
@RoyAwesome That’s definitely a useful feature and is on my todo list. I’ve tried to implemented it a few weeks ago but couldn’t find a way to get the drop event from the graph editor. I’ll have a look at how the blueprint editor does it (when you drag drop function names into the blueprint editor) when I get time
I just tested and couldn’t reproduce the bug. Could you give more info on how the blueprint is built?
@Laurentius it should be possible, I’ll add a flag after the next update (2.5+)
I’ve tested this again and the physics constraint doesn’t work if one of the components is static. I’ve fixed the issue and it will be available in the next build
The issue is fixed and will be available in the next update. This was caused due to an optimization I have while rebuilding the dungeon. On a rebuild, previous dungeon actors that are similar are reused and just moved around (instead of recreating them). I’ve added a flag to mark all actor node created actors as complex actors. These actors would not be reused and will be recreated. This will make the physics and everything work correctly by destroying the old ones and recreating them again. The destructible actor is also marked to be recreated (as we want the fractured mesh state to be reset on a dungeon rebuild at runtime)
@dkoding The physics constraint works fine with the latest dev build at runtime. (Note: I had to move the door a bit up (~15 cm) so the door does not collide with the ground and was not opening)
@dkoding actor scaling issue is fixed