documentation:entrypoint
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
documentation:entrypoint [2020/02/21 23:12] – created jamieswhiteshirt | documentation:entrypoint [2023/12/27 13:07] (current) – ↷ Links adapted because of a move operation 34.220.124.230 | ||
---|---|---|---|
Line 26: | Line 26: | ||
</ | </ | ||
- | **Caution: | + | **Caution: |
==== Built-in entrypoint prototypes ==== | ==== Built-in entrypoint prototypes ==== | ||
- | Fabric Loader provides four built-in entrypoint prototypes for mod initialization, | + | Fabric Loader provides four built-in entrypoint prototypes for mod initialization, |
* **main**: The first normal initialization entrypoint to run. Uses the type '' | * **main**: The first normal initialization entrypoint to run. Uses the type '' | ||
Line 41: | Line 41: | ||
==== Code reference types ==== | ==== Code reference types ==== | ||
- | An entrypoint' | + | An entrypoint' |
* **Class reference**: | * **Class reference**: | ||
Line 55: | Line 55: | ||
Mods can call each others' | Mods can call each others' | ||
- | Entrypoints | + | Entrypoint instances |
- | ==== A note about load order (or lack thereof) ==== | + | Entrypoint instances are memoized by their name and also their type. Using the same code reference for multiple entrypoints will result in multiple instances. Though highly absurd in practice, if '' |
- | Fabric Loader does not have a concept of a load order. Initializer entrypoints are the mechanism with which most mod loading is usually done, but whether | + | ==== A note about load order and phases (or a lack thereof) ==== |
- | A common example is the expectation that a mod has finished populating | + | 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 " |
+ | |||
+ | 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 initializers are not required to represent | ||
+ | - The order in which mod initializers are called is undefined, and cannot be influenced | ||
+ | |||
+ | Leaving aside the missing guarantee of registration of all objects in initializers, |
documentation/entrypoint.1582326735.txt.gz · Last modified: 2020/02/21 23:12 by jamieswhiteshirt