Fabric Wiki

User Tools

Site Tools

Trace:
documentation:entrypoint

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revisionBoth sides next revision
documentation:entrypoint [2020/02/22 00:12] – [Other entrypoint applications] More about getEntrypoints (memoization) jamieswhiteshirtdocumentation:entrypoint [2020/02/22 00:21] – jamieswhiteshirt
Line 59: Line 59:
 ==== A note about load order and phases (or a lack thereof) ==== ==== A note about load order and phases (or a lack thereof) ====
  
-Fabric Loader does not have a concept of a load order or loading phases. Initializer entrypoints are the mechanism with which most mod loading is usually done, but whether or not an initializer has been called does not determine whether or not a mod can be considered to be "loaded". Thus, it is unreasonable to expect that a mod has completed its modifications to the game after its initializers have been called. Additionally, the order in which entrypoints are called is undefined and cannot be altered. Fabric Loader does not provide multiple phases of initializers to work around the lack of order, either.+Fabric Loader does not have a concept of a load order or loading phases. Initializer entrypoints are the mechanism with which most mod loading is usually done, but whether or not an initializer has been called does not determine whether or not a mod can be considered to be "loaded". Thus, it is unreasonable to expect that a mod has completed its modifications to the game after its initializers have been called. Additionally, the order in which entrypoints are called is mostly undefined and cannot be altered. The only guarantee is that a list of initializers in a fabric.mod.json file are called in the order in which they are declared. Fabric Loader does not provide multiple phases of initializers to work around the lack of order, either.
  
 A common example is the expectation that mod A should be able to load after mod B because mod A will replace an object registered by mod B. Alternatively, mod C wants to be loaded before mod D because mod D will do something in response to a registration performed by mod C. This is cannot be done for two reasons: A common example is the expectation that mod A should be able to load after mod B because mod A will replace an object registered by mod B. Alternatively, mod C wants to be loaded before mod D because mod D will do something in response to a registration performed by mod C. This is cannot be done for two reasons:
documentation/entrypoint.txt · Last modified: 2023/12/27 13:07 by 34.220.124.230