Update DunGenExtender
parent
4b999176c3
commit
821b396383
|
@ -8,6 +8,8 @@ If the generation fails to fully create any of the main paths for any reason, it
|
||||||
|
|
||||||
`MainRoomTilePrefab` cannot be null. If set to null, the dungeon generation failsafes to the default vanilla generation behaviour. `MainRoomTilePrefab` can be located practically anywhere on the main path, but it must spawn at least once. It is highly advised that `MainRoomTilePrefab` has multiple doorways at different directions/elevations/distances etc.
|
`MainRoomTilePrefab` cannot be null. If set to null, the dungeon generation failsafes to the default vanilla generation behaviour. `MainRoomTilePrefab` can be located practically anywhere on the main path, but it must spawn at least once. It is highly advised that `MainRoomTilePrefab` has multiple doorways at different directions/elevations/distances etc.
|
||||||
|
|
||||||
|
`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.
|
||||||
|
|
||||||
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`.
|
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
|
||||||
|
@ -36,9 +38,20 @@ Enable this feature by toggling `AddArchetypesToNormalNodes`. This allows 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.
|
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.
|
||||||
|
|
||||||
### 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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
This features adds the slightest bit of slowdown to the dungeon generation times, whether or not the `DoorwaySisters` component is used. As such, if you don't plan to use this feature, it is advised to disable this feature.
|
||||||
|
|
||||||
### 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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
This feature modifies the list of archetypes in `LineRandomizerArchetypes` to receive a random set of tilesets from `LineRandomizerTileSets`. This insures that the archetype will have less overall tiles to progress, and therefore less possible doorway pairs to calculate. Furthermore, since the tilesets received are random the dungeon generation continues to be random, though admittedly less overall.
|
||||||
|
|
||||||
|
`LineRandomizerArchetypes` is the archetypes whose list of tilesets will be modified. Ideally these archetypes will be used in the lines section of `DungeonFlow`. The last `LineRandomizerTakeCount` amount of elements of both the archetype's `TileSets` and `BranchCapTileSets` list will be exchanged by a random set of tilesets from `LineRandomizerTileSets`. As such, the length of those lists must be equal or greater than the value of `LineRandomizerTakeCount`. This goes without saying but be prepared the archetypes' elements to be swapped around all willynilly-ing.
|
||||||
|
|
||||||
### 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. 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.
|
||||||
|
|
Loading…
Reference in New Issue