Update DunGenExtender

Raphtalia 2024-09-03 03:41:17 +00:00
parent af1aad8de1
commit 7d43e6291c
1 changed files with 40 additions and 6 deletions

@ -69,19 +69,53 @@ Enable this feature by toggling `UseForcedTiles`. This attempts to generate addi
The dungeon generation will attempt to generate the tile on every main and branch tile (excluding tiles generated from the Forced Tiles feature). This feature does not guarantee that that tile will generate. If the tile cannot generate for whatever reason, it will simply proceed as normal.
> **NOTE**: Due to current limitations, this feature only works if `MainPathCount` is above 1.
> **NOTE**: This feature may be replicated with injection rules however they are a few key differences.
>
> Injection rules replace main or branch tiles with one of its own tiles when the main and branch paths are being generated. Forced Tiles adds extra tiles after the main and branch paths are generated.
>
> If Injection rules uses a dead-end tile with only one doorway, then the main or branch path will prematurely end (this can cause the dungeon generation to reset). If Forced Tiles uses the same tile, the main or branch path's generation will not be affected.
>
> If Injection rules uses a tile with many doorways on the main path, then those doorways can be used to create branch paths. If Forced Tiles uses the same tile, those doorways will not be used to create branch paths.
## Branch Loop Boost
Enable this feature by toggling `UseBranchLoopBoost`. This causes the dungeon generation to prioritize branch tiles that connect to already generated tiles. This increases the chance of circular/looping paths generating. This feature slows dungeon generation a bit, though it only happens after the main paths are generated (where most of the dungeon generation time is spent).
## Branch Path Multi Simulation
Enable this feature by toggling `UseBranchPathMultiSim`. This causes the dungeon generation to simulate multiple paths for each branch path. It then assigns each path with a weight based on the weights described below. The simulated path with the highest weight will then be chosen and generated. This feature slows dungeon generation a bit, though it only happens after the main paths are generated (where most of the dungeon generation time is spent).
When the dungeon generation is considering which branch tile to place down, it will first consider a maximum amount of `BranchLoopBoostTileSearch` tiles. For each tile considered, its weight will be multiplied by `1 + `x` * n` where `x` is `BranchLoopBoostTileScale` and `n` is the number of additional doorway connections if that tile was selected and generated.
`SimulationCount` is the number of simulated paths per branch path. Increasing this value can increase the chance of finding your desired path, but will increase Branch Path Times and vice versa. Please understand that increasing the chance doesn't guarantee that the perfect path can be found.
> **NOTE**: By itself, this feature only encourages the dungeon generation to generate circular/looping paths. If your interior does not create looping paths naturally by sheer chance, this feature will have very little to no effect.
### Length Weight
These weight scales prioritize long branch paths.
`LengthWeightScale` is the weight scale for the branch path's length. The length of the branch path is multiplied by the scale and is added to the branch path's weight. Increasing this value will prioritize very long branch paths.
`NormalizedLengthWeightScale ` is the weight scale for the branch path's normalized length. The normalized length (0 -> 1) of the branch path (PathLength / MaxPathLength) is multiplied by the scale and is added to the branch path's weight. Increasing this value will prioritize branch paths who meet their maximum path length.
### Same Path Connections Weight
These weight scales prioritize branch paths that connect back to their own main path.
`SamePathBaseWeightScale` is the weight scale for the branch path's number of connections to the same main path. The number of possible connections is multiplied by the scale and is added to the branch path's weight. Increasing this value will prioritize branch paths who make path loops in their main path in general.
`SamePathDepthWeightScale` is the weight scale for the branch path's number of connections to the same main path. For each possible connection, the main path depth difference is multiplied by the scale and is added to the branch path's weight. Increasing this value will prioritize branch paths who make deep path loops to their main paths.
`SamePathNormalizedDepthWeightScale` is the weight scale for the branch path's number of connections to the same main path. For each possible connection, the main path normalized depth difference is multiplied by the scale and is added to the branch path's weight. Increasing this value will prioritize branch paths who make generally deep path loops to their main paths.
### Different Path Connections Weight
These weight scales prioritize branch paths that connect back to other main paths.
`DiffPathBaseWeightScale` is the weight scale for the branch path's number of connections to other main paths. The number of possible connections is multiplied by the scale and is added to the branch path's weight. Increasing this value will prioritize branch paths who make path loops in their main path in general.
`DiffPathDepthWeightScale` is the weight scale for the branch path's number of connections to other main paths. For each possible connection, the main path depth difference is multiplied by the scale and is added to the branch path's weight. Increasing this value will prioritize branch paths who make deep path loops to their other main paths.
`DiffPathNormalizedDepthWeightScale` is the weight scale for the branch path's number of connections to other main paths. For each possible connection, the main path normalized depth difference is multiplied by the scale and is added to the branch path's weight. Increasing this value will prioritize branch paths who make generally deep path loops to other main paths.
> **NOTE**: This feature can encourages the dungeon generation to generate circular/looping paths. However if your interior does not create looping paths naturally by sheer chance, this feature will have very little to no effect.
## 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.
> **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-16 shadow requests is more than enough to stop the warning spam.
<br/><br/>
# Niche Features