merchant_potential_commodities 
Determines what things a merchant might buy or sell, by creating /datum/merchant_commodity instances in bulk.
Place inside of a merchant's potential_[supply|demand] list for them to offer to buy or sell things listed in the decl.
These can be reused between different distinct merchants.
Vars | |
| decl_probability | Determines the odds that everything defined in this decl can be bought or sold. This can be used to make 'rare item' lists that only show up sometimes on a particular merchant. |
|---|---|
| extra_requirements | An assoc list of extra requirements which will be applied to all items that this decl will make.
Keys are /decl/merchant_commodity_requirement types, and values are the parameters for those requirements. |
| item_probability | Determines the odds that an individual type path can be offered, on a per-item basis. |
| item_quantity_lower_bound | The possible lower bound for an item being bought or sold. This is applied on a per-item basis. Does nothing if item_quantity_upper_bound is set to INFINITY.
The default value is 0, which means that it's possible for merchants to start with items already sold out or have a particular demand already satisfied,
if item_quantity_upper_bound is set to a finite value. |
| item_quantity_upper_bound | The possible upper bound for an item being bought or sold. This is applied on a per-item basis. Default value is INFINITY, which makes merchants buy or sell an unlimited number of items. |
| max_distinct_types | Sets a hard cap on how many datums can be retrieved from this decl. |
| type_instructions | An assoc list which is used to determine what types a merchant will offer to buy or sell.
The format is the type path as the key, and a MERCHANT_* bitflag as the value.
Multiple types, similar or otherwise, can be in the same decl, forming a set that is only affected by the data inside the decl.
Example: list(/obj/item/foo = MERCHANT_INCLUDE_ALL, /obj/item/foo/bar = MERCHANT_EXCLUDE_THIS_TYPE) will generate commodity instances for
/obj/item/foo and all of its subtypes, except for /obj/item/foo/bar.
The list is evaluated sequentially, so order matters. Put excludes below the includes.
Seperating into different decls is generally only needed if you plan to have different items have different quantities, probabilities, or requirements,
if you want to buy both regular items and things like reagents/gases, or you want to reuse item lists across different merchants. |
Procs | |
| post_init | Exists for cross-modpack interactions, mainly for adding type exclusions. |
Var Details
decl_probability
Determines the odds that everything defined in this decl can be bought or sold. This can be used to make 'rare item' lists that only show up sometimes on a particular merchant.
extra_requirements
An assoc list of extra requirements which will be applied to all items that this decl will make.
Keys are /decl/merchant_commodity_requirement types, and values are the parameters for those requirements.
item_probability
Determines the odds that an individual type path can be offered, on a per-item basis.
item_quantity_lower_bound
The possible lower bound for an item being bought or sold. This is applied on a per-item basis. Does nothing if item_quantity_upper_bound is set to INFINITY.
The default value is 0, which means that it's possible for merchants to start with items already sold out or have a particular demand already satisfied,
if item_quantity_upper_bound is set to a finite value.
item_quantity_upper_bound
The possible upper bound for an item being bought or sold. This is applied on a per-item basis. Default value is INFINITY, which makes merchants buy or sell an unlimited number of items.
max_distinct_types
Sets a hard cap on how many datums can be retrieved from this decl.
type_instructions
An assoc list which is used to determine what types a merchant will offer to buy or sell.
The format is the type path as the key, and a MERCHANT_* bitflag as the value.
Multiple types, similar or otherwise, can be in the same decl, forming a set that is only affected by the data inside the decl.
Example: list(/obj/item/foo = MERCHANT_INCLUDE_ALL, /obj/item/foo/bar = MERCHANT_EXCLUDE_THIS_TYPE) will generate commodity instances for
/obj/item/foo and all of its subtypes, except for /obj/item/foo/bar.
The list is evaluated sequentially, so order matters. Put excludes below the includes.
Seperating into different decls is generally only needed if you plan to have different items have different quantities, probabilities, or requirements,
if you want to buy both regular items and things like reagents/gases, or you want to reuse item lists across different merchants.
Proc Details
post_init
Exists for cross-modpack interactions, mainly for adding type exclusions.