Open Mirsario opened 2 years ago
If this is added I believe it would benefit greatly from passes being able to be positioned relative to single other passes which they don't rely on
Previous discussion summary (scroll up for context): https://discord.com/channels/103110554649894912/445276626352209920/1011402588371038251
Similarly to #2139, this is a proposal for modernization of everything related to generation layers.
Current Design
First, have a look at the common usage of the current (1.3) TML's generation pass designs:
(Taken from Itorius' ModularTools)
Why do anything?
These are the 'problems' that the following design will attempt to solve:
ModSystem
s) and leave too much in the hands of API users. For example: caching generation pass instances, writing layer insertion code defensively, etc. The former has likely never been done right, and the lack of the latter in mods has been a common pain for many years -- a ton of mods that add tooltips, which use the same design, have had many cases of conflicts with mods that remove or modify vanilla tooltips.ModifyWorldGenTasks
,ModifyHardmodeTasks
, with people having asked forModifyAltarTasks
, and with support for modifying meteor spawning also nowhere to be found.Proposal
Everything past this point may be incomplete and poorly written, somewhat of a sketch.
The suggested solution for the first problem is nothing unexpected by now - like with interface layers, we somewhat copy the design of player layers from #1047.
The latter two problems are solvable by making generations be instanced, and perhaps having generation types use the type system.
Here's a short, non-final summary of suggested changes:
Generation Passes:
GenPass
(or a derivative) class a self-sufficientModType
, withModSystem.ModifyInterfaceLayers
hooks removed in favor of automatic registration.Terraria.DrawStructures.PlayerDrawLayers
class.PassLegacy
class, or its constructor, would be turnedinternal
.Generation Types:
WorldGeneration
class, instances of which will contain lists of enabled generation passes, copies of which will be further modified during generation starts.Default
,Hardmode
,AltarSmash
Meteor
default generations as static{ get; }
properties onWorldGeneration
, orWorldGenerations
classes. Whatever sounds best?WorldGeneration
instances, invoking hooks for toggling genpasses' appearance on them.New usage sketch
Each genpass will be able to go into its own file, and enable themselves for initializing world generations. Types deriving from
WorldGeneration
will be able to modify their own default lists of enabled generation passes. Hooks (supposedly in ModSystems) will allow people will be the last to modify already defined visibility of genpasses on world generations.