sorcery  Diff

if you need to change `sorcery`'s behavior in a way that isn't possible through modifying the lore, you can create a file `$world/sorcery/finalize.lua` which will be run at the end of the init process and which will have access to all of the machinery created by the various modules of the mod. `worldbuilding.lua` is like `finalize.lua` but it is run before any lore is loaded. finally, `bootstrap.lua` will be run before anything else, including library code, is loaded, but after the core `sorcery` structure and its loading functions have been created.

in the unlikely event that the lore-loading process itself is incompatible with the changes you're trying to make, you can create a `loadlore.lua` file that will be run instead of the usual routine. you'll then be responsible for loading all of the game's lore; the default lore will not even be read! this will be most useful if you're loading or generating your own lore from an unusual source, such as somewhere on the network.

if you want to write a lore loader but include some of the default lore, you can use the loading function passed to `loadlore.lua`:

```
-- /srv/mt/geographica/loadlore.lua
local load_lore, load_module = ...
sorcery.data = dofile('load-remote-lore.lua')
load_lore {'enchants', 'spells'}
```

as you can see here, once the lore is loaded, it is stored in the variable `data`. there is a subtle distinction you need to bear in mind: `data` represents the full set of lore-derived information `sorcery` has to work with, which is not necessarily the same as the lore itself. for example, certain modules could generate extra information and attach them to the entries in the `data` table, which can be (and is) written to at runtime. the one invariant that the `data` table should observe is that once a record is added, it may neither be mutated nor removed (though additional sub-records can always be added) -- `sorcery` is not written to handle such eventualities and it may produce anything from glitches to crashes. the term `lore` references specifically the core records stored on disk from which the `data` table is generated, and a `lorepack` is a full, integrated collection of lore. (there are cases where modifying or deleting from `data` may be necessary for a `sorcery`-aware mod, for instance to prevent players from creating a certain default potion, but this is very fraught and you should only ever do it if you thoroughly understand the internals and exactly what you're doing, with the caveat that what works in this version may break the next.)

................................................................................
		description = sorcery.lib.str.capitalize(name) .. ' Extract Keg';
		color = sorcery.lib.color(data[2]):hex();
		‹···›
	})
end)
```

but in the on_metadata_inventory_put code for keg-filling node, to identify the proper keg, we might instead use code like

```
local inv = minetest.get_meta(pos):get_inventory()
local fluid = inv:get_stack('fluid',1)
if fluid:get_count() < 99 then return end

local fname = fluid:get_name()

if you need to change `sorcery`'s behavior in a way that isn't possible through modifying the lore, you can create a file `$world/sorcery/finalize.lua` which will be run at the end of the init process and which will have access to all of the machinery created by the various modules of the mod. `worldbuilding.lua` is like `finalize.lua` but it is run before any lore is loaded. finally, `bootstrap.lua` will be run before anything else, including library code, is loaded, but after the core `sorcery` structure and its loading functions have been created.

in the unlikely event that the lore-loading process itself is incompatible with the changes you're trying to make, you can create a `loadlore.lua` file that will be run instead of the usual routine. you'll then be responsible for loading all of the game's lore; the default lore will not even be read! this will be most useful if you're loading or generating your own lore from an unusual source, such as somewhere on the network.

if you want to write a lore loader but include some of the default lore, you can use the loading function passed to `loadlore.lua`:

```
-- /srv/mt/geographica/sorcery/loadlore.lua
local load_lore, load_module = ...
sorcery.data = dofile('load-remote-lore.lua')
load_lore {'enchants', 'spells'}
```

as you can see here, once the lore is loaded, it is stored in the variable `data`. there is a subtle distinction you need to bear in mind: `data` represents the full set of lore-derived information `sorcery` has to work with, which is not necessarily the same as the lore itself. for example, certain modules could generate extra information and attach them to the entries in the `data` table, which can be (and is) written to at runtime. the one invariant that the `data` table should observe is that once a record is added, it may neither be mutated nor removed (though additional sub-records can always be added) -- `sorcery` is not written to handle such eventualities and it may produce anything from glitches to crashes. the term `lore` references specifically the core records stored on disk from which the `data` table is generated, and a `lorepack` is a full, integrated collection of lore. (there are cases where modifying or deleting from `data` may be necessary for a `sorcery`-aware mod, for instance to prevent players from creating a certain default potion, but this is very fraught and you should only ever do it if you thoroughly understand the internals and exactly what you're doing, with the caveat that what works in this version may break the next.)

................................................................................
		description = sorcery.lib.str.capitalize(name) .. ' Extract Keg';
		color = sorcery.lib.color(data[2]):hex();
		‹···›
	})
end)
```

but in the `on_metadata_inventory_put` code for keg-filling node, to identify the proper keg, we might instead use code like

```
local inv = minetest.get_meta(pos):get_inventory()
local fluid = inv:get_stack('fluid',1)
if fluid:get_count() < 99 then return end

local fname = fluid:get_name()