Wiki data model - Revision history

76561197969631737: /* Examples */ editing and updating pass

2024-11-16T04:13:25Z

Examples: editing and updating pass

← Older revision		Revision as of 04:13, 16 November 2024
Line 54:		Line 54:

	[[File:Recipe_panel_example.png\|thumb\|400px\|Example from the in-game recipe book]]		[[File:Recipe_panel_example.png\|thumb\|400px\|Example from the in-game recipe book]]
	Therefore, in order to display something like what the game has in the recipe book, ~~the~~ [[Template:Recipe]] ~~template needs~~ the ~~following data:~~		Therefore, in order to display something like what the game has in the recipe book, [[Template:Recipe]] invokes the [[Module:RecipeController]]. The Controller makes multiple calls to the model to assemble the following information before sending it to the View for rendering and returning that markup to fill in the template:
	* '''Module:~~WorkshopsRecipesData'''~~
	** recipe ID to ~~match with workshop data~~
	** efficiency grade
	** production time
	** good ID of the ~~product~~
	** stack size of the ~~product~~
	** ingredients
	*** groups of alternative ingredients
	**** good ID of the ~~ingredient~~
	**** stack size of the ~~ingredient~~

	* ~~'''~~Module:WorkshopsData~~'''~~		* [[Module:BaseDataModel]] and (for example) [[Module:WorkshopsData]]:
			** building ID
	** display name of the building		** display name of the building
	** ~~recipe~~ ID ~~to match with recipe data~~		** building icon
	** ~~icon~~		** information for recipes:
			*** efficiency grade
			*** production time
			*** slots (or groups) of single (or swappable) ingredients:
			**** stack size of the ingredient option
			**** good ID of the ingredient option
			*** stack size of the product
			*** good ID of the product

	* '''Module:GoodsData'''		* '''Module:GoodsData'''
	** good ID ~~to match with product and ingredient data~~		** good ID
	** display name of the good		** display name of the good
	** icon		** icon

	This template implements a Model–View–Controller ~~framework~~. When you write <code><nowiki>{{Recipe\|Biscuits}}</nowiki></code>, the [[Module:RecipeController]] mediates everything. It requests ~~any data where~~ Biscuits ~~is the product~~ from ~~all~~ of those modules~~, so they don't~~ have to know anything about how ~~the~~ data is displayed. The ~~controller~~ then ~~send~~ piecemeal data to [[~~Module~~:~~RecipeView~~]] which owns all of the layout~~, and the controller only~~ has to know that it~~'s adding things~~ row~~-by-row--nothing specific about the layout~~. The View then returns ~~everything once fully assembled~~, and the ~~controller sends it~~ directly to the page to display.		This template implements a Model–View–Controller pattern. When you write <code><nowiki>{{Recipe\|Biscuits}}</nowiki></code>, the [[Module:RecipeController]] mediates everything. It requests recipes for Biscuits from most of those modules. The data Models never have to know anything about how data is used or displayed. The Controller then sends piecemeal data to the View, starting with [[Template:Recipe/view]], which owns all of the formatting and layout. The Controller never has to know anything about MediaWiki or HTML markup, just that it provides information one recipe at a time to [[Template:Recipe/view/row]]. The View then returns the rendered information in the form of wiki or HTML markup, and the Controller returns that directly to the page to display.

	=== Second example ===		=== Second example ===

	A second example, ~~we also display~~ tables of perks, drawing from ~~'''~~Module:PerksData.~~'''~~ This also ~~implements a~~ Model–View–Controller ~~framework~~. ~~You~~ call <code><nowiki>{{~~PerkSearch~~\|...}}</nowiki></code>, and [[Module:~~PerkSearchController~~]] ~~mediates fetching the~~ data, ~~applying~~ the ~~search~~ logic, and then ~~handing~~ each entry, row-by-row, to [[Module:~~PerkSearchResultsView~~]] which owns everything about display and layout. ~~It assembles~~ the rows, ~~storing~~ it all until the ~~controller is~~ finished, ~~applies any final layout~~, and then returns the entire display to the ~~controller~~, which forwards it without any additional processing back to the page to display.		A second example, [[Template:Perks]] displays tables of perks, drawing from [[Module:PerksData]]. This is also an implementation of the Model–View–Controller pattern. Authors call <code><nowiki>{{Perks\|...}}</nowiki></code>, and [[Module:PerksController]] fetches data, applies the detailed selection and exclusion logic, and then hands each entry, row-by-row, to [[Module:PerksView]] which owns everything about display and layout. The View lays out and formats the rows, caching it all until the Controller tells it it's finished, finalizes the display, and then returns the entire display to the Controller, which forwards it without any additional processing back to the page to display.

76561197969631737: /* Data Model */ editing and updating pass

2024-11-16T03:27:06Z

Data Model: editing and updating pass

← Older revision		Revision as of 03:27, 16 November 2024
Line 13:		Line 13:
	When authors include a template in an article, the template waits for a reader to visit that article. (Templates do not pre-compute anything.) When the page loads, the template invokes a Controller. The Controller knows how the author wanted the data to be displayed on that page and which data to display because of the template parameters. The Controller grabs data from one or more Model modules and re-organizes it to suit the purposes of the template. The Controller then calls the View template or module, which lays out and formats whatever the Controller gives it. The Controller then makes any final adjustments, but usually just immediately returns what the View made. This is what appears on the page.		When authors include a template in an article, the template waits for a reader to visit that article. (Templates do not pre-compute anything.) When the page loads, the template invokes a Controller. The Controller knows how the author wanted the data to be displayed on that page and which data to display because of the template parameters. The Controller grabs data from one or more Model modules and re-organizes it to suit the purposes of the template. The Controller then calls the View template or module, which lays out and formats whatever the Controller gives it. The Controller then makes any final adjustments, but usually just immediately returns what the View made. This is what appears on the page.

	== Data ~~Model~~ ==		== Data Models ==

	The data is spread across multiple Models (modules whose names end in ''Data'') and related via unique identifiers (IDs) for goods, buildings, and effects like perks. There is one Model for each of the different data files provided by the developers, so that each Model can own its data file. The Models own retrieval, sorting and reorganizing, and serving queries for information from Controllers. This means that Controllers do not retrieve entire data sets, but smaller subsets of the data—ideally the minimum necessary per page view, rather than loading the entire game data on every page load even if only a small section is needed for a given page.		The data is spread across multiple Models (modules whose names end in ''Data'') and related via unique identifiers (IDs) for goods, buildings, and effects like perks. There is one Model for each of the different data files provided by the developers, so that each Model can own its data file. The Models own retrieval, sorting and reorganizing, and serving queries for information from Controllers. This means that Controllers do not retrieve entire data sets, but smaller subsets of the data—ideally the minimum necessary per page view, rather than loading the entire game data on every page load even if only a small section is needed for a given page.
Line 19:		Line 19:
	Here are the Models on our wiki. If you need to write a new template with new functionality, you will need to write a new Controller that connects to the appropriate Models and a new View to standardize the display of that information and make it easily maintainable. The primary data dimensions that relate the data together across Models are called out.		Here are the Models on our wiki. If you need to write a new template with new functionality, you will need to write a new Controller that connects to the appropriate Models and a new View to standardize the display of that information and make it easily maintainable. The primary data dimensions that relate the data together across Models are called out.

	See each module's pages for complete documentation on that module.		See each module's pages for complete documentation on that module, to see when it was last updated, and to find which data file it loads so you can see when that was last updated.

	*Building statistics, including things like construction goods, category, recipes, and icons:		=== List of Data Models ===
	** [[Module:CampsData]]
	*** '''camp ID''' of ~~the building~~
	*** '''camp display name'''
	*** '''good ID''' of the resource node that are gathered, but the secondary gathered goods are not included in the data
	** [[Module:CollectorsData]], for industry buildings that sit on resource nodes or passively collect
	*** '''collector ID''' of the building
	*** '''collector display name'''
	*** '''good ID''' of the resources collected
	** [[Module:FarmsData]]
	*** '''farm ID'''
	*** '''farm display name'''
	*** '''good ID''' of the resource harvested
	** [[Module:WorkshopsData]], for industry buildings and some food production buildings
	*** '''workshop ID'''
	*** '''workshop display name'''
	*** '''recipe ID''' of the recipes available
	** [[Module:InstitutionsData]]
	*** '''workshop ID'''
	*** '''workshop display name'''
	*** '''recipe ID''' of the services provided

	*~~Recipe statistics~~, including ~~goods~~ and ~~efficiency grades~~:		* '''Building data,''' including things like description, construction costs, category, recipes, and icon:
	** [[Module:~~WorkshopsRecipesData~~]]		** [[Module:BaseDataModel]], an abstract class that specifies three important '''interfaces''' for querying building data models and also provides default implementations for the interfaces. See the luadoc at the top of the module for the description of the interfaces and list of methods. The following are instances of <code>BaseDataModel</code>:
	~~***~~ '''~~recipe ID~~''' for ~~production recipes~~		*** [[Module:CampsData]], for the Woodcutters' Camp.
	*** '~~''product ID''' of~~ the ~~good produced~~		*** [[Module:CollectorsData]], currently blank but should include the Mine in a future update.
	*** ~~'''ingredients'''~~, ~~a list of good IDs required or optional~~		*** [[Module:FarmsData]], for everything that grows things on Farm Fields.
	** [[Module:~~ServicesRecipesData~~]]		*** [[Module:FarmFieldsData]], for Farm Fields themselves.
	*** ~~'''recipe ID'''~~ for ~~services recipes~~		*** [[Module:FishingData]], for the small and large Fishing Huts.
	*** ~~'''~~service ~~display name'''~~		*** [[Module:GatheringData]], for gathering camps that work deposits on the map.
	*** ~~'''service goods'''~~, a ~~list~~ of ~~good IDs required~~		*** [[Module:HearthsData]], for the Ancient and buildable Hearths.
			*** [[Module:InstitutionsData]], for service buildings.
			*** [[Module:RainCollectorsData]], for the Advanced and regular Rain Collector.
			*** [[Module:WarehousesData]], for the Main and buildable Warehouses.
			*** [[Module:WorkshopsData]], for industry buildings and some food production buildings.
			** [[Module:BuildingDataProxy]], a utility class that federates method calls to all building data Models, providing an extra layer of indirection between Controllers and the Models. Useful when aggregating data across all building types or when you only need information from the basic building interface. {{c\|{{ColorRed}}\|Expensive for some data,}} because it naively loads the data models one-at-a-time until the right one is found—better to choose the Models you need whenever possible.

	*Goods ~~statistics~~, including whether it is food or fuel, trading value, and ~~icons~~:		* '''Goods and services data,''' including category, whether it is food or fuel, trading value, and icon:
	** [[Module:GoodsData]]		** [[Module:GoodsData]], currently stores all information for all goods.
	*** '''~~goodID~~'''		** [[Module:ServicesData]], currently no more than a shortcut model that actually references data in [[Module:InstitutionsData]] but in a way that mimics GoodsData.
	*** '''~~good display name~~'''
			* '''Perks data,''' including description, sources, and icon:
			** [[Module:AltarEffectsData]], for all Stormforged Cornerstones.
			** [[Module:MysteriesData]], for all Forest Mysteries.
			** [[Module:PerksData]], for all Cornerstones.

			* '''Species data,''' including resolve parameters, specializations, and icon:
			** [[Module:SpeciesData]], for the species themselves.
			** [[Module:SpecializationsData]], currently a hard-coded data set that can be used directly by Controllers.

	== Examples ==		== Examples ==

76561197969631737: /* Data Model */ editing and updating pass

2024-11-16T02:51:14Z

Data Model: editing and updating pass

← Older revision		Revision as of 02:51, 16 November 2024
Line 15:		Line 15:
	== Data Model ==		== Data Model ==

	The ~~Model~~ is spread across multiple ~~data managers~~ (modules whose names end in ''Data'') and ~~connected~~ via unique IDs ~~(identifiers~~) for ~~recipes,~~ goods, buildings, and ~~services~~. ~~These are separated according to~~ the different data files provided by the developers, ~~but also provide a way~~ for Controllers to retrieve smaller subsets of the ~~data for each~~ page ~~viewed~~, rather than loading the entire game data on every page load even if only a small section is needed for a given page.		The data is spread across multiple Models (modules whose names end in ''Data'') and related via unique identifiers (IDs) for goods, buildings, and effects like perks. There is one Model for each of the different data files provided by the developers, so that each Model can own its data file. The Models own retrieval, sorting and reorganizing, and serving queries for information from Controllers. This means that Controllers do not retrieve entire data sets, but smaller subsets of the data—ideally the minimum necessary per page view, rather than loading the entire game data on every page load even if only a small section is needed for a given page.

			Here are the Models on our wiki. If you need to write a new template with new functionality, you will need to write a new Controller that connects to the appropriate Models and a new View to standardize the display of that information and make it easily maintainable. The primary data dimensions that relate the data together across Models are called out.

	See each module's pages for complete documentation on that module.		See each module's pages for complete documentation on that module.

	Here are the data modules available in our Model. If you need to write a new template with new functionality, you will need to write a new Controller that connects to the Model via one or more of these modules. The primary data that relates these modules together and connect to Controllers are called out.

	*Building statistics, including things like construction goods, category, recipes, and icons:		*Building statistics, including things like construction goods, category, recipes, and icons:

76561197969631737: /* Overview */ editing and updating pass

2024-11-16T02:43:42Z

Overview: editing and updating pass

← Older revision		Revision as of 02:43, 16 November 2024
Line 3:		Line 3:
	The data model on this wiki serves up information on-demand to guests to our wiki site. Page authors can connect use the data model to serve up large amounts of accurate information consistently across pages.		The data model on this wiki serves up information on-demand to guests to our wiki site. Page authors can connect use the data model to serve up large amounts of accurate information consistently across pages.

	Because this is the official wiki, the Eremite Games developers provide us with new drops of data every ~~few versions~~. Our wiki data isn't updated automatically when the game patches, but the data model has been set up in such a way to make ~~incorporating the~~ new data as easy as possible ~~to keep up with the game updates~~.		Because this is the official wiki, the Eremite Games developers provide us with new drops of data almost every version. Our wiki data isn't updated automatically when the game patches, but the data model has been set up in such a way to make uploading and automatically propagating changes from new data as easy as possible.

	=== ~~Model-View-Controller~~ concept ===		=== Model–View–Controller concept ===

	Pages on the wiki include [https://www.mediawiki.org/wiki/Help:Templates~~/en~~ Templates] that invoke [https://www.mediawiki.org/wiki/Extension:Scribunto~~/tl~~ Lua modules enabled by the Scribunto extension].		Pages on the wiki include [https://www.mediawiki.org/wiki/Help:Templates Templates] that invoke [https://www.mediawiki.org/wiki/Extension:Scribunto Lua modules enabled by the Scribunto extension].

	When ~~you write~~ a ~~new page and you use~~ an ~~existing template~~, ~~that~~ template waits for a ~~wiki guest~~ to ~~view your page~~. When the page loads, the template invokes a Controller. The Controller knows how ~~you,~~ the author, wanted the data to be displayed on that page because of the template parameters ~~you wrote~~. The Controller ~~uses your template parameters to determine which~~ data ~~to grab~~ from ~~the~~ Model ~~module(s)~~ and ~~how~~ to ~~organize~~ the ~~data when it is displayed~~. The Controller then calls the View module~~(s) to perform the actual layout~~ and ~~formatting of~~ the ~~data, so that~~ it~~'s consistent across pages~~. The Controller then makes ~~the~~ final ~~assembly and~~ returns what the View ~~wrote, which~~ is what appears on the page.		Most of the data-driven parts of this wiki are implemented in a [https://en.wikipedia.org/wiki/Model-view-controller Model—View—Controller design pattern.]

			When authors include a template in an article, the template waits for a reader to visit that article. (Templates do not pre-compute anything.) When the page loads, the template invokes a Controller. The Controller knows how the author wanted the data to be displayed on that page and which data to display because of the template parameters. The Controller grabs data from one or more Model modules and re-organizes it to suit the purposes of the template. The Controller then calls the View template or module, which lays out and formats whatever the Controller gives it. The Controller then makes any final adjustments, but usually just immediately returns what the View made. This is what appears on the page.

	== Data Model ==		== Data Model ==

76561197969631737: /* Example */ Added another example

2024-02-04T15:59:00Z

Example: Added another example

← Older revision		Revision as of 15:59, 4 February 2024
Line 56:		Line 56:
	*** '''good display name'''		*** '''good display name'''

	== ~~Example~~ ==		== Examples ==

	[[File:Recipe_panel_example.png\|thumb\|400px\|Example from the in-game recipe book]]		[[File:Recipe_panel_example.png\|thumb\|400px\|Example from the in-game recipe book]]
Line 82:		Line 82:

	This template implements a Model–View–Controller framework. When you write <code><nowiki>{{Recipe\|Biscuits}}</nowiki></code>, the [[Module:RecipeController]] mediates everything. It requests any data where Biscuits is the product from all of those modules, so they don't have to know anything about how the data is displayed. The controller then send piecemeal data to [[Module:RecipeView]] which owns all of the layout, and the controller only has to know that it's adding things row-by-row--nothing specific about the layout. The View then returns everything once fully assembled, and the controller sends it directly to the page to display.		This template implements a Model–View–Controller framework. When you write <code><nowiki>{{Recipe\|Biscuits}}</nowiki></code>, the [[Module:RecipeController]] mediates everything. It requests any data where Biscuits is the product from all of those modules, so they don't have to know anything about how the data is displayed. The controller then send piecemeal data to [[Module:RecipeView]] which owns all of the layout, and the controller only has to know that it's adding things row-by-row--nothing specific about the layout. The View then returns everything once fully assembled, and the controller sends it directly to the page to display.

			=== Second example ===

			A second example, we also display tables of perks, drawing from '''Module:PerksData.''' This also implements a Model–View–Controller framework. You call <code><nowiki>{{PerkSearch\|...}}</nowiki></code>, and [[Module:PerkSearchController]] mediates fetching the data, applying the search logic, and then handing each entry, row-by-row, to [[Module:PerkSearchResultsView]] which owns everything about display and layout. It assembles the rows, storing it all until the controller is finished, applies any final layout, and then returns the entire display to the controller, which forwards it without any additional processing back to the page to display.

76561197969631737: /* Example */ finished the MVC description for the example

2023-12-06T02:17:13Z

Example: finished the MVC description for the example

← Older revision		Revision as of 02:17, 6 December 2023
Line 80:		Line 80:
	** display name of the good		** display name of the good
	** icon		** icon

			This template implements a Model–View–Controller framework. When you write <code><nowiki>{{Recipe\|Biscuits}}</nowiki></code>, the [[Module:RecipeController]] mediates everything. It requests any data where Biscuits is the product from all of those modules, so they don't have to know anything about how the data is displayed. The controller then send piecemeal data to [[Module:RecipeView]] which owns all of the layout, and the controller only has to know that it's adding things row-by-row--nothing specific about the layout. The View then returns everything once fully assembled, and the controller sends it directly to the page to display.

76561197969631737: /* Data Model */ added collectors

2023-12-06T02:12:31Z

Data Model: added collectors

← Older revision		Revision as of 02:12, 6 December 2023
Line 24:		Line 24:
	*** '''camp display name'''		*** '''camp display name'''
	*** '''good ID''' of the resource node that are gathered, but the secondary gathered goods are not included in the data		*** '''good ID''' of the resource node that are gathered, but the secondary gathered goods are not included in the data
			** [[Module:CollectorsData]], for industry buildings that sit on resource nodes or passively collect
			*** '''collector ID''' of the building
			*** '''collector display name'''
			*** '''good ID''' of the resources collected
	** [[Module:FarmsData]]		** [[Module:FarmsData]]
	*** '''farm ID'''		*** '''farm ID'''

76561197969631737: /* Model-View-Controller concept */ fixed the external links

2023-11-22T17:31:30Z

Model-View-Controller concept: fixed the external links

← Older revision		Revision as of 17:31, 22 November 2023
Line 7:		Line 7:
	=== Model-View-Controller concept ===		=== Model-View-Controller concept ===

	Pages on the wiki include [[https://www.mediawiki.org/wiki/Help:Templates/en\|Templates]] that invoke [[https://www.mediawiki.org/wiki/Extension:Scribunto/tl\|Lua modules enabled by the Scribunto extension]].		Pages on the wiki include [https://www.mediawiki.org/wiki/Help:Templates/en Templates] that invoke [https://www.mediawiki.org/wiki/Extension:Scribunto/tl Lua modules enabled by the Scribunto extension].

	When you write a new page and you use an existing template, that template waits for a wiki guest to view your page. When the page loads, the template invokes a Controller. The Controller knows how you, the author, wanted the data to be displayed on that page because of the template parameters you wrote. The Controller uses your template parameters to determine which data to grab from the Model module(s) and how to organize the data when it is displayed. The Controller then calls the View module(s) to perform the actual layout and formatting of the data, so that it's consistent across pages. The Controller then makes the final assembly and returns what the View wrote, which is what appears on the page.		When you write a new page and you use an existing template, that template waits for a wiki guest to view your page. When the page loads, the template invokes a Controller. The Controller knows how you, the author, wanted the data to be displayed on that page because of the template parameters you wrote. The Controller uses your template parameters to determine which data to grab from the Model module(s) and how to organize the data when it is displayed. The Controller then calls the View module(s) to perform the actual layout and formatting of the data, so that it's consistent across pages. The Controller then makes the final assembly and returns what the View wrote, which is what appears on the page.

76561197969631737: Created to explain the data model and provide links to the data modules

2023-11-22T17:26:54Z

Created to explain the data model and provide links to the data modules

New page

== Overview ==

The data model on this wiki serves up information on-demand to guests to our wiki site. Page authors can connect use the data model to serve up large amounts of accurate information consistently across pages.

Because this is the official wiki, the Eremite Games developers provide us with new drops of data every few versions. Our wiki data isn't updated automatically when the game patches, but the data model has been set up in such a way to make incorporating the new data as easy as possible to keep up with the game updates.

=== Model-View-Controller concept ===

Pages on the wiki include [[https://www.mediawiki.org/wiki/Help:Templates/en|Templates]] that invoke [[https://www.mediawiki.org/wiki/Extension:Scribunto/tl|Lua modules enabled by the Scribunto extension]].

When you write a new page and you use an existing template, that template waits for a wiki guest to view your page. When the page loads, the template invokes a Controller. The Controller knows how you, the author, wanted the data to be displayed on that page because of the template parameters you wrote. The Controller uses your template parameters to determine which data to grab from the Model module(s) and how to organize the data when it is displayed. The Controller then calls the View module(s) to perform the actual layout and formatting of the data, so that it's consistent across pages. The Controller then makes the final assembly and returns what the View wrote, which is what appears on the page.

== Data Model ==

The Model is spread across multiple data managers (modules whose names end in ''Data'') and connected via unique IDs (identifiers) for recipes, goods, buildings, and services. These are separated according to the different data files provided by the developers, but also provide a way for Controllers to retrieve smaller subsets of the data for each page viewed, rather than loading the entire game data on every page load even if only a small section is needed for a given page.

See each module's pages for complete documentation on that module.

Here are the data modules available in our Model. If you need to write a new template with new functionality, you will need to write a new Controller that connects to the Model via one or more of these modules. The primary data that relates these modules together and connect to Controllers are called out.

*Building statistics, including things like construction goods, category, recipes, and icons:
** [[Module:CampsData]]
*** '''camp ID''' of the building
*** '''camp display name'''
*** '''good ID''' of the resource node that are gathered, but the secondary gathered goods are not included in the data
** [[Module:FarmsData]]
*** '''farm ID'''
*** '''farm display name'''
*** '''good ID''' of the resource harvested
** [[Module:WorkshopsData]], for industry buildings and some food production buildings
*** '''workshop ID'''
*** '''workshop display name'''
*** '''recipe ID''' of the recipes available
** [[Module:InstitutionsData]]
*** '''workshop ID'''
*** '''workshop display name'''
*** '''recipe ID''' of the services provided

*Recipe statistics, including goods and efficiency grades:
** [[Module:WorkshopsRecipesData]]
*** '''recipe ID''' for production recipes
*** '''product ID''' of the good produced
*** '''ingredients''', a list of good IDs required or optional
** [[Module:ServicesRecipesData]]
*** '''recipe ID''' for services recipes
*** '''service display name'''
*** '''service goods''', a list of good IDs required

*Goods statistics, including whether it is food or fuel, trading value, and icons:
** [[Module:GoodsData]]
*** '''goodID'''
*** '''good display name'''

== Example ==

[[File:Recipe_panel_example.png|thumb|400px|Example from the in-game recipe book]]
Therefore, in order to display something like what the game has in the recipe book, the [[Template:Recipe]] template needs the following data:
* '''Module:WorkshopsRecipesData'''
** recipe ID to match with workshop data
** efficiency grade
** production time
** good ID of the product
** stack size of the product
** ingredients
*** groups of alternative ingredients
**** good ID of the ingredient
**** stack size of the ingredient

* '''Module:WorkshopsData'''
** display name of the building
** recipe ID to match with recipe data
** icon

* '''Module:GoodsData'''
** good ID to match with product and ingredient data
** display name of the good
** icon