Yogstation 13 - Modules - TypesVar Details - Proc Details

Wardrobe

Vars

cache_intensityHow much to cache outfit items Multiplier, 2 would mean cache enough items to stock 1 of each preloaded order twice, etc
canon_minimumCanonical list of types required to fill all preloaded stocks once. Type -> list(count, last inspection timestamp, call on insert, call on removal)
current_taskWhat we're currently doing
initial_callbacksList of type -> list(insertion callback, removal callback) callbacks for insertion/removal to use. Set in setup_callbacks, used in canonization.
inspect_delayHow often to inspect our stock, in deciseconds
last_inspect_timeThe last time we inspected our stock
one_go_masterHow many items would we make just by loading the master list once?
order_listList of types to load. Type -> count //(I'd do a list of lists but this needs to be refillable)
overflow_lienencyHow many more then the template of a type are we allowed to have before we delete applicants?
preloaded_stockList of lists. Contains our preloaded atoms. Type -> list(last inspect time, list(instances))
stock_hitHow many times we've successfully returned a cached item
stock_missHow many times we've had to generate a stock item on request

Procs

canonize_typeCanonizes the type, which means it's now managed by the subsystem, and will be created deleted and passed out to comsumers
get_callback_typeTakes a path to get the callback owner for Returns the deepest path in our callback store that matches the input The hope is this will prevent dumb conflicts, since the furthest down is always going to be the most relevant
hard_refresh_queueResets the load queue to the master template, accounting for the existing stock
run_inspectionOnce every medium while, go through the current stock and make sure we don't have too much of one thing Or that we're not too low on some other stock This exists as a failsafe, so the wardrobe doesn't just end up generating too many items or accidentially running out somehow
setup_callbacksSets up insertion and removal callbacks by typepath We will always use the deepest path. So /obj/item/blade/knife superceeds the entries of /obj/item and /obj/item/blade Mind this
stash_objectTake an existing object, and insert it into our storage If we can't or won't take it, it's deleted. You do not own this object after passing it in
stock_wardrobeTurns the order list into actual loaded items, this is where most work is done
unload_stockUnloads an amount of some type we have in stock Private function, for internal use only

Var Details

cache_intensity

How much to cache outfit items Multiplier, 2 would mean cache enough items to stock 1 of each preloaded order twice, etc

canon_minimum

Canonical list of types required to fill all preloaded stocks once. Type -> list(count, last inspection timestamp, call on insert, call on removal)

current_task

What we're currently doing

initial_callbacks

List of type -> list(insertion callback, removal callback) callbacks for insertion/removal to use. Set in setup_callbacks, used in canonization.

inspect_delay

How often to inspect our stock, in deciseconds

last_inspect_time

The last time we inspected our stock

one_go_master

How many items would we make just by loading the master list once?

order_list

List of types to load. Type -> count //(I'd do a list of lists but this needs to be refillable)

overflow_lienency

How many more then the template of a type are we allowed to have before we delete applicants?

preloaded_stock

List of lists. Contains our preloaded atoms. Type -> list(last inspect time, list(instances))

stock_hit

How many times we've successfully returned a cached item

stock_miss

How many times we've had to generate a stock item on request

Proc Details

canonize_type

Canonizes the type, which means it's now managed by the subsystem, and will be created deleted and passed out to comsumers

Arguments:

get_callback_type

Takes a path to get the callback owner for Returns the deepest path in our callback store that matches the input The hope is this will prevent dumb conflicts, since the furthest down is always going to be the most relevant

hard_refresh_queue

Resets the load queue to the master template, accounting for the existing stock

run_inspection

Once every medium while, go through the current stock and make sure we don't have too much of one thing Or that we're not too low on some other stock This exists as a failsafe, so the wardrobe doesn't just end up generating too many items or accidentially running out somehow

setup_callbacks

Sets up insertion and removal callbacks by typepath We will always use the deepest path. So /obj/item/blade/knife superceeds the entries of /obj/item and /obj/item/blade Mind this

stash_object

Take an existing object, and insert it into our storage If we can't or won't take it, it's deleted. You do not own this object after passing it in

stock_wardrobe

Turns the order list into actual loaded items, this is where most work is done

unload_stock

Unloads an amount of some type we have in stock Private function, for internal use only