Wardrobe
Vars | |
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 |
Procs | |
canonize_type | Canonizes the type, which means it's now managed by the subsystem, and will be created deleted and passed out to comsumers |
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 |
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:
- type to stock - What type exactly do you want us to remember?
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