Raphtalia
/
DungeonGenerationPlus_LethalCompany_Mod
1
1
Fork 0
Code Issues 1 Pull Requests Packages Projects Releases Wiki Activity

Update DunGenExtender

Raphtalia 2024-07-26 10:24:24 +00:00
parent 1c0af9b097
commit dd9caa2876
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
DunGenExtender.md

@ -1,7 +1,7 @@
### Dungeon Flow ## Dungeon Flow
The `DungeonFlow` that the `DunGenExtender` asset will influence. Each `DungeonFlow` can only one `DunGenExtender`. The `DungeonFlow` that the `DunGenExtender` asset will influence. Each `DungeonFlow` can only one `DunGenExtender`.
### Main Path ## Main Path
`MainPathCount` is the amount of main paths that the dungeon try to generate. If set to 1, then the dungeon generation will default to the vanilla behaviour of, well, generating only one main path and its branching paths. If set to 3, then the dungeon generation will try to create two additional main paths from the first `MainRoomTilePrefab` tile in the base main path. It will then create the branching paths for each main path. `MainPathCount` is the amount of main paths that the dungeon try to generate. If set to 1, then the dungeon generation will default to the vanilla behaviour of, well, generating only one main path and its branching paths. If set to 3, then the dungeon generation will try to create two additional main paths from the first `MainRoomTilePrefab` tile in the base main path. It will then create the branching paths for each main path.
If the generation fails to fully create any of the main paths for any reason, it will reset the entire dungeon generation and try again. The length of these additional main paths is the same as the base main path, and its starting node for length calculation purposes is at the base main path's starting node. If the generation fails to fully create any of the main paths for any reason, it will reset the entire dungeon generation and try again. The length of these additional main paths is the same as the base main path, and its starting node for length calculation purposes is at the base main path's starting node.
@ -10,11 +10,11 @@ If the generation fails to fully create any of the main paths for any reason, it
`MainRoomTilePrefab` must be present in at least one tileset in `DungeonFlow's` node list as a normal node. All nodes after the first normal node with `MainRoomTilePrefab` will be duplicated for the main paths generation. Injection tiles will not duplicated. `MainRoomTilePrefab` must be present in at least one tileset in `DungeonFlow's` node list as a normal node. All nodes after the first normal node with `MainRoomTilePrefab` will be duplicated for the main paths generation. Injection tiles will not duplicated.
`MainRoomTilePrefab` can be used in conjunction with the `MainRoomDoorwayGroups` component for more control in which doorways that the alternate main paths choose. See here for details. `MainRoomTilePrefab` can be used in conjunction with the `MainRoomDoorwayGroups` component for more control in which doorways that the alternate main paths choose. See [here](https://git.touhou.dev/Raphtalia/DungeonGenerationPlus_LethalCompany_Mod/wiki/Components#user-content-main-room-doorway-groups) for details.
> **NOTE:** Adding an additional main path is effectively adding an entire side dungeon to your interior. This is due to the fact that it not only adds a set amount of main tiles, but also branching paths with their tiles. It is highly recommended to decrease the length of the dungeon as you increase `MainPathCount`. > **NOTE:** Adding an additional main path is effectively adding an entire side dungeon to your interior. This is due to the fact that it not only adds a set amount of main tiles, but also branching paths with their tiles. It is highly recommended to decrease the length of the dungeon as you increase `MainPathCount`.
### Dungeon Bounds ## Dungeon Bounds
Enable this feature by toggling `UseDungeonBounds`. This adds a bounds to your interior where the dungeon generation cannot place tiles outside of. This can help preventing the dungeon from creating paths all the way to Narnia. Enable this feature by toggling `UseDungeonBounds`. This adds a bounds to your interior where the dungeon generation cannot place tiles outside of. This can help preventing the dungeon from creating paths all the way to Narnia.
> **NOTE:** This feature also increases the chance of the dungeon generation failing, and therefore increasing dungeon generation times. This can even make dungeon generation impossible if the bounds is too small or mispositioned. > **NOTE:** This feature also increases the chance of the dungeon generation failing, and therefore increasing dungeon generation times. This can even make dungeon generation impossible if the bounds is too small or mispositioned.
@ -36,15 +36,15 @@ Bounds GetDungeonBounds(float dungeonScale) {
} }
``` ```
### Archetypes on Normal Nodes ## Archetypes on Normal Nodes
Enable this feature by toggling `AddArchetypesToNormalNodes`. This allows normal nodes in `DungeonFlow` to create branching paths by attaching an archetype to it. Enable this feature by toggling `AddArchetypesToNormalNodes`. This allows normal nodes in `DungeonFlow` to create branching paths by attaching an archetype to it.
Each element of the `NormalNodeArchetypes` list represents which node receives an archetype. The `Label` describes which normal node of the same `Label` will receive one of the archetypes in the `Archetypes` list. If the `Label` is empty or white-spaced, then it becomes the default target for any normal node who did not have a corresponding `Label` in the `NormalNodeArchetypes` list. If a normal node does not have any corresponding target, then it's spawned tile will not create branching paths like normal. Each element of the `NormalNodeArchetypes` list represents which node receives an archetype. The `Label` describes which normal node of the same `Label` will receive one of the archetypes in the `Archetypes` list. If the `Label` is empty or white-spaced, then it becomes the default target for any normal node who did not have a corresponding `Label` in the `NormalNodeArchetypes` list. If a normal node does not have any corresponding target, then it's spawned tile will not create branching paths like normal.
> **NOTE:** Start and End nodes cannot receive archetypes. > **NOTE:** Start and End nodes cannot receive archetypes.
### Doorway Sisters ## Doorway Sisters
Enable this feature by toggling `UseDoorwaySisters`. This feature requires the usage of the `DoorwaySisters` component to do anything. This prevents an intersecting doorway from generating into an actual doorway IF it's sister doorway has already generated AND both of these doorways lead to the intersecting, neighbor tile. Enable this feature by toggling `UseDoorwaySisters`. This feature requires the usage of the `DoorwaySisters` component to do anything. This prevents an intersecting doorway from generating into an actual doorway IF it's sister doorway has already generated AND both of these doorways lead to the intersecting, neighbor tile. See here for that [component's details](https://git.touhou.dev/Raphtalia/DungeonGenerationPlus_LethalCompany_Mod/wiki/Components#user-content-doorway-sisters).
When the dungeon is generating, two tiles may generate right next to each other and one of each of their doorways may be intersecting at the same position. This is an intersecting doorway. The dungeon generation will then roll to see if it will generate the intersecting doorway as an actual doorway. However there is a possibility that when that doorway spawns, it will have a locked door and a neighboring, already generated, doorway will have an open door. If both doorways were to lead to the same tile, then it will defeat the whole purpose of the locked door. This is the scenario that this feature was designed for. When the dungeon is generating, two tiles may generate right next to each other and one of each of their doorways may be intersecting at the same position. This is an intersecting doorway. The dungeon generation will then roll to see if it will generate the intersecting doorway as an actual doorway. However there is a possibility that when that doorway spawns, it will have a locked door and a neighboring, already generated, doorway will have an open door. If both doorways were to lead to the same tile, then it will defeat the whole purpose of the locked door. This is the scenario that this feature was designed for.
@ -52,7 +52,7 @@ This features adds the slightest bit of slowdown to the dungeon generation times
> **NOTE**: This feature is probably not necessary for your interior. My interior was designed to pack my tiles very closely and for their doorways to have a high chance of intersecting. As such, my interior developed the issue of having too many unnecessary doorways and required this feature to fix it. Most interiors won't have this same issue. > **NOTE**: This feature is probably not necessary for your interior. My interior was designed to pack my tiles very closely and for their doorways to have a high chance of intersecting. As such, my interior developed the issue of having too many unnecessary doorways and required this feature to fix it. Most interiors won't have this same issue.
### Line Randomizer ## Line Randomizer
Enable this feature by toggling `UseLineRandomizer`. This helps dungeons with the combination of a large amount of tiles and/or large amount of doorways for each tile to generate a bit faster while maintaining some of the dungeon generation randomness. Enable this feature by toggling `UseLineRandomizer`. This helps dungeons with the combination of a large amount of tiles and/or large amount of doorways for each tile to generate a bit faster while maintaining some of the dungeon generation randomness.
When the dungeon is generating and trying to add a new tile, it will try and insert every possible tile and each of its doorways to the previous tile's doorway. As the amount of tiles increases and the amount of doorways per tiles increases, this number of possible doorway pairs can very quickly gets out of hand. This can drastically increase dungeon generation times if not addressed. This is the scenario that this feature was designed for. When the dungeon is generating and trying to add a new tile, it will try and insert every possible tile and each of its doorways to the previous tile's doorway. As the amount of tiles increases and the amount of doorways per tiles increases, this number of possible doorway pairs can very quickly gets out of hand. This can drastically increase dungeon generation times if not addressed. This is the scenario that this feature was designed for.
@ -63,7 +63,7 @@ This feature modifies the list of archetypes in `LineRandomizerArchetypes` to re
> **NOTE**: This feature is probably not necessary for your interior. My interior was reaching up to 2000 potential doorway pairs for each tile injection and needed a way to reduce it. And even with this fix, the doorway pairs bubble sort rewrite was probably the bigger performance boost anyway. Still, I needed a way to future-proof my dungeon generation times and such this feature still exists. > **NOTE**: This feature is probably not necessary for your interior. My interior was reaching up to 2000 potential doorway pairs for each tile injection and needed a way to reduce it. And even with this fix, the doorway pairs bubble sort rewrite was probably the bigger performance boost anyway. Still, I needed a way to future-proof my dungeon generation times and such this feature still exists.
### Max Shadows Request ## Max Shadows Request
Enable this feature by toggling `UseMaxShadowsRequestUpdate`. This prevents the `Max shadow requests count reached` warning spam that can appear if the interior has too many lights in close proximity. `MaxShadowsRequestAmount` will become the new amount of shadow requests. Enable this feature by toggling `UseMaxShadowsRequestUpdate`. This prevents the `Max shadow requests count reached` warning spam that can appear if the interior has too many lights in close proximity. `MaxShadowsRequestAmount` will become the new amount of shadow requests.
> **NOTE**: By default, Lethal Company uses 4 shadow requests. I find from my experience that 8 shadow requests is more than enough to stop the warning spam. > **NOTE**: By default, Lethal Company uses 4 shadow requests. I find from my experience that 8 shadow requests is more than enough to stop the warning spam.