Clothing Booth - The clothing booth is a machine that allows users to purchase clothing items by interacting with a sophisticated front-end interface. The interface supports various forms of tagging, filtering, and sorting with the goal of enabling the ease of exploration of the full catalogue and searching for the exact type of item desired quickly with minimal friction.
HUDZones - HUDZones are a new way to manage HUD elements on a mob's screen.
They're a rectangular region on a screen that registered elements will automatically position themselves in as you add more.
meat_derelict - Meat Zone
Contents:
Meaty areas
Stomach acid turf & such
Meat lights. Not to be confused with Spam Lite reduced fat meat-like protein product.
Grumpy meat-infested monster doors, monster floors, mutant cosmonauts, and a very sad giant head.
Various log files.
Audio logs
Fancy items in the land of meat
Puzzle elements
Gross mutant limbs
moon - Lunar Moon Museum Zone
Contents:
Moon Areas
Moon turfs
Moon emails
A tourguid bud
Museum objects
Control Panel Puzzle
A li'l fake bomb for an exhibit.
Very Legitimate Pawn Shop - Areas That Walp Uses For Gimmick Maps To Load In
prison/cell_block/Asylum Wards - Used for the admin holding cells.
Regina Anchorage - new merchant areas
Research Outpost - Off-station research outpost. Used for Cog2.
Salvager Vessel Magpie Space - Used to allow the exterior of the Magpie to render parallax layers.
Shame Cube - Shamecube area, applied on the admin command. Blocks entry.
hotspot - The object that represents fire ingame. Very nice and warm.
chemfire - chemical/magical fire. represents a fire coming from a chemical or magical source
gasfire - fire created by a gaseous source. or atmos fire.
maptext_holder - Maptext holders are atom/movables that are attached to a parent maptext manager, and are responsible for displaying maptext
images to a single client. When maptext is required to be displayed to a client, the parent maptext manager will instruct the
maptext holder associated with that client to add a line of maptext to itself and add it to the client's images list.
maptext_manager - Maptext manager atom/movables govern displaying maptext over single parent atom. To this end, they track the outermost movable
of the parent atom, and relocate to the outermost loc if possible. To display maptext to a client, the list of maptext holders
indexed by their associated clients is queried for the maptext holder associated with that client, and instructed to add a line.
minimap_render_object - Just a helper type to ensure all minimap render parts have the correct vis_flags set
minimap_ui_handler - Minimap UI handles are responsible for all TGUI logic pertaining to minimaps and minimap controllers. This typically
involves setting up the ByondUI to display the minimap and passing other parameters to the UI.
parallax_render_source - Parallax render sources are screens that hold the appearance data for a specific type of parallax layer; this appearance
is then drawn to client parallax layers using render targets and sources. This permits the appearance of a specific parallax
layer to be edited at runtime and efficiently distributed across all applicable clients.
callback - Calls a specified proc if it finishes without interruptions. Only displayed to the user.
Heavily copy pasted from /datum/action/bar/icon/callback.
ambushing - If a target is in range and we're hiding, attack them until they're incapacitated
critter
attacking - This one makes the critter move towards a target returned from holder.owner.seek_target()
attacking target - This one makes the critter move towards a fixed target
eating - This one makes the critter move towards a food item returned from holder.owner.seek_food_target()
maintain distance - This makes the critter maintain a distance and fire on the target from holder.owner.seek_target() if the target gets close we back away.
attacking at range - This makes the critter maintain a distance and fire on the target from holder.owner.seek_target() if the target gets close we back away.
scavenging - This one makes the critter move towards a corpse returned from holder.owner.seek_scavenge_target()
barricading - Since we don't want flockdrones building barricades randomly, this task only exists for the targetable version to inherit from
build/targetable - Targetable AI tasks, instead of looking for targets around them they just override with their own target var
retaliating - This one makes the mob move towards a target mob and attack it. Repeats until the target is dead, gone, too far, or we are incapacitated. Called upon being attacked if the ai is set to retaliate
hiding - If a target can see us and we're not hiding, then lets run away and hide
succeedable
critter
attack subtask - The aiTask/succeedable handles the behaviour to do when we're in range of the target
flee subtask - The aiTask/succeedable handles the behaviour to do when we're in range of the target
ranged attack subtask - The aiTask/succeedable handles the behaviour to do when we're in range of the target
air_group - Air groups are collections of tiles that let us save processing time by treating a bunch of similar tiles as a single tile.
This is quite useful because atmospherics processing is quite the time hog and processing one tile is much faster.
Whenever our tiles become too different, we can break up and create new smaller groups.
allocated_region - Represents a map region you have allocated access to.
While you hold a reference to this region you are free to assume nothing else will allocate this part of the map and touch your region.
You should also not go out of its bounds of course.
Deallocate the region by qdel()ing it or dropping all references to it.
antagPopups - Singleton that handles antag popups, use get_singleton
antagonist_panel - Antagonist panel datums serve as per-UI-user datums that pass data fetched from the global antagonist panel data singleton
to the UI. These datums will also store and pass user specific data such as the current tab and subordinate antagonist data
requested by the UI user.
antagonist_panel_data - The global singleton datum responsible for generating and providing data to individual instances of antagonist panels.
Such a datum is necessary due to the relatively large amount of antagonist data that is required to be processed with
each update of individual antagonist panels; tab data may be collated once every update then stored in a cache in order
to be fetched by antagonist panels.
antagonist_panel_tab - Antagonist panel tab datums represent the individual tabs that may be present on an antagonist panel and are responsble
for generating the specific data contained within them.
dectalk/play - POST /dectalk/play
Generate an audio file speaking the text provided.
gameadminrank/post - POST /game-admin-ranks
Add a new game admin rank
gameadminranks
delete - DELETE /game-admin-ranks/{gameAdmin}
Delete an existing game admin
get - GET /game-admin-ranks
List paginated and filtered game admin ranks
put - PUT /game-admin-ranks/{gameAdminRank}
Update an existing game admin
gameadmins
delete - DELETE /game-admins/{gameAdmin}
Delete an existing game admin
get - GET /game-admins
List paginated and filtered game admins
post - POST /game-admins
Add a new game admin
put - PUT /game-admins/{gameAdmin}
Update an existing game admin
gamebuilds/build - POST /game-builds/build
Trigger a build for a given server
gauntlet/getprevious - GET /gauntlets/get-previous
Retrieve a count of how many gauntlets a given key has completed
jobbans
add - POST /job-bans
Add a new job ban
check - GET /job-bans/check
Check if a job ban exists for given player and server details
delete - DELETE /job-bans/{jobBan}
Delete an existing job ban
get - GET /job-bans
List filtered and paginated job bans
getforplayer - GET /job-bans/get-for-player
Get all job bans for a given player and server
update - PUT /job-bans/{jobBan}
Update an existing job ban
numbersstation/get - GET /numbers-station
Get the current numbers representing the password for the numbers station terminal
players
antags - POST /players/antags
Add a player antagonist for a given round
compids/get - GET /players/get-compids
Get a list of computed IDs associated with a player ckey, along with how many times they connected with each computer ID
ips/get - GET /players/get-ips
Get a list of IPs associated with a player ckey, along with how many times they connected with each IP
login - POST /players
Register a login for a player with associated details
medals
add - POST /medals
Add a medal for a player
delete - DELETE /medals
Delete medal for a player
get - GET /medals
List paginated and filtered player medals
has - GET /medals/has
Determine if a player has a medal
transfer - POST /medals/transfer
Transfer medals from one player to another
metadata
add - ADD /players/metadata
Add player metadata
delete - DELETE /players/metadata/clear-by-data/{metadata}
Delete a specific item of metadata
fromplayer - DELETE /players/metadata/clear-by-player/{ckey}
Delete all metadata associated with a specific player
get - GET /players/metadata
List paginated and filtered player metadata
getbydata - GET /players/metadata/get-by-data/{metadata}
Get all the ckeys associated with a piece of metadata
getbyplayer - GET /players/metadata/get-by-player/{ckey}
Get all the metadata associated with a ckey
notes
delete - DELETE /players/notes/{note}
Delete list
get - GET /players/notes
List paginated and filtered player notes
post - POST /players/notes
Add a new player note
update - PUT /players/notes/{note}
Update
participations - POST /players/participation
Add a player participation for a given round
participationsBulk - POST /players/participation
Add a player participation for a given round
playtime - POST /players/playtime/bulk
Record playtime for a list of players
saves
data
delete - DELETE /players/saves/data
Delete data for a player
post - POST /players/saves/data
Add player data
databulk/post - POST /players/saves/data-bulk
Add multiple entries of player data
file
delete - DELETE /players/saves/file/{playerSave}
Delete a save for a player
post - POST /players/saves/file
Add player save
transfer - POST /players/saves/transfer-files
Transfer all save files from a player to another
WARNING: This overwrites all the saves for the target
get - GET /players/saves
List all data and saves for a player
stats/get - GET /players/stats
Get various statistics associated with a player
polls
add - POST /polls
Add a new poll
delete - DELETE /polls/{poll}
Delete an existing poll
edit - PUT /polls/{poll}
Edit an existing poll
get - GET /polls
List paginated and filtered polls
options
add - POST /polls/option/{poll}
Add a new option to an existing poll
delete - DELETE /polls/option/{pollOption}
Delete an existing poll
edit - PUT /polls/option/{pollOption}
Update an existing poll option
pick - POST /polls/option/pick/{pollOption}
Register that a player picked a poll option
unpick - POST /polls/option/unpick/{pollOption}
Register that a player removed their pick of a poll option
show - GET /polls/{poll}
Get a specific poll
randomEntries - GET /random-entries
Get a list of random entries by type
remoteMusic - POST /remote-music
Queue a piece of music from youtube to be played in a given round
rounds
end - PUT /rounds/end/{gameRound}
End a game round.
post - POST /rounds
Start a new game round
update - PUT /rounds/{gameRound}
Update a game round. This should be used when game round data we care about is set after the start of the round.
test - GET /test
Test route for debugging
vpn/check - GET /vpncheck/{ip}
Check if a player is using a VPN
vpnwhitelist
add - POST /vpncheck-whitelist
Add a player into the whitelist. This will allow them to skip VPN checks.
delete - DELETE /vpncheck-whitelist
Delete a whitelist entry
search - GET /vpncheck-whitelist/search
Check if a player is whitelisted from the VPN checker
assembly_signal_helper - ///////////////////////////////////// Assembly signal helper /////////////////////////////////
This datum exists because we cannot return anything else than bitflags in signals. So we pass this with the signal and have it modified by whatever catches the signal at the end.
portableCore - Chemicompiler
v1.0 By volundr 9/24/14
This device is a programmable chemistry mixing and heating device.
The javascript code to run the frontend is in browserassets/src/js/chemicompiler.min.js
which is minified javascript from browserassets/src/js/chemicompiler.js
If you make changes to the uncompressed javascript, you'll need to install node.js,
and run npm install -g uglify-js
then run uglifyjs browserassets/src/js/chemicompiler.js -c > browserassets/src/js/chemicompiler.min.js to rebuild the compressed version.
<code>clothingbooth_item_tag</code> datum - Tags can be used to further sort clothingbooth_groupings into more specific categorisations, such as by seasonality, formality, as a set that
is intended to be paired with items of another grouping, etc. An arbitrary number of these can be assigned to any given grouping to an extent that
is reasonable.
<code>clothingbooth_item</code> datum - A purchaseable item from the clothing booth. These are the constituent parts of a broader clothingbooth_grouping, though such groupings may - as
part of the organisational scheme of the clothing booth - contain only one item.
analyzable - Makes an object scannable by the device analyzer.
The result type is drawn from either the parent's typepath or its mechanics_type_override.
Syndicate objects can't be scanned by non-Syndicate scanners.
manual_water - Plantpot must be watered manually (interacted with like a hydroponics tray clicking directly on the plant)
single_use - Component will destoy itself after plantpot is destroyed
assembly - This component calls a procref with a assembly_information string on the atom it was added to when it gets attacked with an object specified in the to_combine_item
This component can be used to get the convulent if-then-else trees of assemblies under control
Make the proc you call on sucessfull assembly return TRUE. Else the attack will go through!
trigger_applier_assembly - This component handles the creation of modular trigger-applier-assemblies
bubble_absorb - Componentized behaviour for sucking up bubbles into a gas mixture datum of some kind
Necessary because atmos inheritance is a fuck
bullet_holes - A component which makes bullet holes appear on a thing when it gets shot
complexsignal - Handler for a complex singal, that is a signal that requires some additional handling.
You define such signal for example as:
#define XSIG_OUTERMOST_MOVABLE_CHANGED list(/datum/component/complexsignal/outermost_movable, "mov_outermost_changed")
When this signal gets registered at least once once to a datum the appropriate complex signal component will get registered to it.
When all instances of this signal get unregistered then the component will qdel itself unless [qdel_when_unneeded] is unset.
The intended use is for this component to keep some more complex and resource intensive handling (possibly using other signals) and then send the
actual complex signal when some conditions are met. That signal should be set to src like this:
SEND_COMPLEX_SIGNAL(src, X_OUTERMOST_MOVABLE_CHANGED, old_outermost, new_outermost)
consume - handles various overrides regarding eating things, like making certain inedible things edible, or eaten organs restore health
can_eat_raw_materials - Eating rocks
food_effects - Applies some status effects when eaten
fake_attack - Fake attack - hallucinate being attacked by something
fake_singulo - Fake singulo - hallucinate a loose singularity approaching you and eating the station
random_image - Random image - hallucinate an image on a visible tile with prob per life tick
random_image_override - Random image override - hallucinate an image on a filtered atom either in or out of view in range with prob per life tick, with an option to add as overlay or replace the icon
random_sound - Random sound - play a sound from a list with a prob per life tick
trippy_colors - Trippy colors - apply an RGB swap to client's vision
target_coordinates - a pitfall which targets a coordinate. At the moment only supports targeting a z level and picking a range around current coordinates.
mainframe program - Mainframe programs represent computer programs, and are responsible for carrying out an instruction or set of instructions
specified by commands passed to them. Unlike real computer programs, mainframe programs are not in possession of any ingame
representation of "source code" and are hardcoded. Most of DWAINE's functionality is provided by computer programs, which
include the kernel, the shell, the drivers, and system utilities (ls, cd, etc...), among other programs.
Login - The user login manager is responsible for passing user login credentials from the user to the kernel to be authenticated,
displaying the daily welcome message to the user, and for notifying the user in the event of a login failure.
Kernel - The kernel is the computer program at the core of the OS and is responsible for managing interactions with all hardware
devices, such as terminals, databanks, scanners and so forth through device drivers; for handling inputs; for creating and
terminating connections; for the execution of system calls; and for other basic system services.
ai_tracking - Handles the AI camera tracking players
air_system - handles air processing.
area_process - Controller for misc. processing on areas
Areas will only process when active (player inside)
Calls /area/proc/area_process, register your area to [TR_CAT_AREA_PROCESS]
arena - Handles the gauntlet
blob - Handles blobs without being pissy about it
camnets - Handles rebuilding of camnets if needed
chemistry - Handles chemistry reactions
critters - handles critters
cross_server_sync - proocess for cross server data syncing
delete_queue - The process controller for queued deletion
ticker - handles the game ticker, for gamemodes and such
timers - NB: this is just for the item timers used to make pipebombs etc.
did u know timers have been horribly inaccurate at short durations all this time? well no more!!
world - Handles various global init and the position of the sun.
data_input_result - A datum holding the data the caller needs- the formatted output itself and the format the src selected (text, JSON, color, etc etc)
Functionally a named tuple.
debugFileOutput - This is a generic handler for logging your dumb JS errors generated by html popups
digbot_ui - Digbot UI
digital_filter - Provide support for IIR filters to perform all your standard filtering needs!
Previous inputs and outputs of the function will be summed together and output
exponential_moving_average - Sum weighted current input and weighted previous output to achieve output
input weight will be ratio of weight assigned to input value while remaining goes to previous output
window_average - Sum equally weighted previous inputs of window_size
eventRecord - Base eventCall type
Represents a predefined event we can send to the Goonhub event recorder
SECURITY: Sanitization occurs right before output
AILaw - Record a new AI law
Antag - Record an antag spawn
AntagItemPurchase - Record an antag item purchase
AntagObjective - Record an antag objective addition
BeeSpawn - Record a bee spawn
CyborgModuleSelection - Record initial cyborg module selection
Death - Record a player death
Error - Record an error
Fine - Record a new fine
GauntletHighScore - Record a new gauntlet high score
Log - Record a log message
StationName - Record a new station name
Ticket - Record a new ticket
eventRecordBody - Represents the body of an event - ABSTRACT
TracksPlayer - For events that require a player ID - ABSTRACT
fishing_lootpool - This code handles different lootpools for fishing
A fishing_lootpool is a datum that stores unified loottables for certain conditions on fishing
These loottables created in new()of a fishing spot and are added to a fishing spot.
These, in contrast to fishing spots, are NOT singletons, since they can be added and removed dynamically (for cases such as a fishing component)
Once someone tries to fish somewhere, proc/generate_fish iterate through all fishing_lootpools and generates a list to pick its fish from
Since fishing_lootpools have their own conditionals, this enables different loottables for e.g. different tier rods or other things such as baits
When adding loottables, is should be paid attention to that a loottable is avaible there.
charred_remains - charred items you potentionally can find in lava or the oven in the kitchen
clown_shoes_loot - extra loot from their shoes for clowns only
igneous_fish - A mid-tier fish you can find in hot places.
lava_fish - lava fish as T3 fish for fire-sources
pufferfish - requires meat to get pufferfish from exotic sources
real_goldfish - REAL goldfish will eat the FAKE goldfish
standard - Here can the lootpools be found
Standard lootpool for the standard fishing tank
tiny_junk - tiny junk items you can find in vending machines and others.
fishing_spot - a datum that holds all the information about a "fishing spot"
language - Language datums are responsible for modifying say message datums depending on whether they have been understood by the listener.
The listen module tree of the listener determines whether a message has been understood, then passes it to the respective proc
on the langauge datum of the langauge that the message was sent in.
hot - Currently used by the High Fever disease which is obtainable from the "Too Much" chem which only shows up in sickly pears, which are currently commented out. Go there to make use of this.
small_critter - little critters with teeth, like mice! can pick up small items only. There are some checks in critter.dm, which might need to be updated with whatever you edit here.
med - same as the parent, but can pick up some heavier shit
swipe_quake - test for crab attack thing
tentacle - I wanted a claw-like limb but without the random item pickup fail
listen_module - Listen module datums serve as a parent type for listen inputs and listen modifiers, which exist to modify and format say
message datums passed to them from a say channel or listen module tree respectively.
control - Listen control module datums permit the manipulation of other listen modules to be linked to a module that may be added to a
listen module tree.
client_verb - Client verb listen control module datums permit other listen modules to be manipulated through the use of a verb added to a
client. The module handles updating client verb lists as they log in and out of the parent tree's listener parent.
effect - Listen effect module datums handle all hearing effects associated with receiving a say message datum. They determine what
happens to a message after the parent listen tree has finished processing it. Typically the final destination of say message
datums.
input - Listen input module datums modify say message datums passed to them from the say channel that they are subscribed to, then
in turn pass the message to their parent listen module tree for further processing.
bundled - Bundled listen input module datums operate in a similar manner to ordinary listen inputs, however instead of receiving every
message passed over an ordinary say channel, they are subscribed to specific subchannel of a bundled say channel.
modifier - Listen modifier module datums exist to modify and format say message datums passed to them by a listen module tree.
listen_module_tree - Listen module tree datums handle applying the effects of languages and listen modifier modules to say message datums
received by any listen input modules registered to itself. Processed messages are then stored in the message buffer
before being sent to listen effect modules.
auxiliary - Auxiliary listen module tree datums handle adding and removing their own modules to a specified target listen module
tree, and transferring modules when the target changes. These are used as listen module trees for datums that
frequently change between atoms with their own trees, such as clients or minds.
listener_tick_cache - Listener tick caches are responsible for storing the "listeners by type" lists calculated by PassToChannel() for a single tick.
This allows all other hearing operations occuring on the same tick from the same origin to quickly retrieve the relevant listeners;
this is why speaking into over ten radios at once doesn't grind the game to a halt.
listening_post - Listening post prefab loading, because copy/pasting the changes between every map for every tweak sucks.
map_generator - This type is responsible for any map generation behavior that is done in areas, override this to allow for area-specific map generation. This generation is ran by areas on world/proc/init().
message_modifier - Message modifier datums permit sayflags to modify the say message datum that they are applied to. This is either performed
prior to a message is sent to an output module, or as the message is being formatted for output after it has been received,
depending on the subtype used.
minimap - Minimap datums are responsible for handling the appearance of the minimap. This includes any displayed markers, the zoom level,
and the displayed z-level.
minimap_marker - Minimap marker datums are responsible for managing the appearance and position of a marker atom/movable that depicts a
tracked target object.
minimap_render_modifier - Minimap render modifiers are responsible for handling alterations to the pixel colour that represent a specific turf on
a minimap. Only one modifier may apply its effects to a pixel at a time, with higher priority modifiers being considered
first.
minimap_renderer - The minimap renderer is responsible for generating partial renders of area minimaps for each minimap type flag and generating
full renders of radar minimaps, alongside updating radar minimaps and dynamic area overlays. In the case of querying for area
minimaps, a minimap type bitflag may be passed to the renderer, which will then return a full render of the map comprised of
the aforementioned partial renders. In the case of querying for radar minimaps, a minimap atom/movable will be returned,
containing both the radar map icon and the radar map markers.
mining_encounter/Miraclium asteroid - TELESCOPE ENCOUNTERS BELOW
Movable Preview - Essentially, it creates a movable on a 1x1 map and gives you access to the it for modification.
Character Preview - This is intended only for use with humans. preview_thing will be a subtype of generic human.
multiclient - A shared character preview between multiple clients.
Again, use winset() to position the control.
window - Manages its own window.
Basically a simplified version for when you don't need to put other stuff in the preview window.
outermost_listener_tracker - Outermost listener trackers are responsible for handling the logic used to track an atom's outermost listener. They are typically
only required for atoms that speak or listen to a local delimited say channel.
parallax_render_source_group - The parent type for parallax render source groups, which govern which parallax render sources should be shown to a client
in a given area or z-level. They also allow for the efficient manipulation of parallax render sources and layers within a
specified z-level or area, permitting more granular control over the appearance of parallax render sources.
area - Area render source groups are singleton datums stored in a lookup table by type. They permit areas of differing type paths
to share parallax render source instances and therefore permit parallax render source changes to take effect across several
areas consistantly.
planet - Planet render source groups are non-singleton datums, with each instance of each type varying in parallax render source
settings. They are assigned to planet areas during the procedural generation of planets, and permit variety in parallax
layers amongst planets.
z_level - Z-level render source groups are singleton datums stored in a lookup table by z-level. Their default parallax render source
types are defined by the current map settings, with each z-level render source group using the list on the map settings datum
corresponding to its z-level. See map.dm and the Z_LEVEL_PARALLAX_RENDER_SOURCES() macro.
plantgrowth_tick - plantgrowth_tick is a container that saves information about changes that are happening within a plant during a tick.
This is passed to procs of chems and plantgenes and is modified
After plantgenes, chems and plant-effects are resolved, this proc can be resolved and removed with /obj/machinery/plantpot/proc/HYPresolve_plantgrowth_tick
proc_ownership_cache - The proc ownership cache is responsible for handling the generation and storage of proc ownership data. This is necessary
because BYOND offers no method to access or check which procs a type defines, overrides, or inherits.
rc_entry - Requisition contract entry: analyzes things passed to it, returns whether they were needed, and is checked for completion at end of analyses.
stack - Stackable item entry. Remarkably, used for items that can be stacked.
something - Item reward datum optionally used in contract creation.
Should generally return an object, or set of objects that makes sense as a list entry (i.e. "fast food meal" for a burger, fries and soda).
To use: in a contract's New(), instantiate one of these and add it to src.item_rewarders.
region_allocator_panel - admin panel front end for interacting with the region allocator system
Requisition Contract - The primary datum for requisitions contracts.
Top level contains cargo handling data, payout data, item reward generators if present, and formatted descriptions for the QM requisitions menu.
aid - Aid contracts are a class of standard (market-listed) contract.
Uniquely among contracts, aid contracts can't be pinned due to their urgency,
and will leave after a certain number of market cycles instead of at random.
Requirements and flavor text should convey this urgency.
civilian - Civilian contracts are a class of standard (market-listed) contract.
These contracts should typically be somewhat "tame", revolving around what a station might need in normal, non-catastrophe operation.
If you can picture a station or colony needing something for expansion, or under-provisioned it, it's a good candidate for a Civilian contract.
scientific - Scientific contracts are a class of standard (market-listed) contract.
Of the contract types, these should typically lean more heavily on unusual materials or ones that require a sophisticated acquisition process.
This doesn't have to be limited to what the science department puts out; if a researcher somewhere wants it, that could be a contract.
special - Contracts for utilisation by the special order event.
These are distinguished by the requisition being sent physically, either standalone or in a crate with stuff.
They are not inspected by the requisitions handler, and do not receive the screwup protection that is afforded to regular contracts.
They do not appear in the general market.
Two-Beep - Ringtones that'll get mashed into a PDA
Retrospection - basic-ass ringtones for basic-ass spacepeople
Nooty's Tooter - Clown ringtones
WOLF PACK - Test ringtone for random sounds w/ varied and altered pitch
Norman Number's Counting Safari - Test ringtone for cycled numbers with special index
BEEP 2: The Fourth - Ringtones with Shorts
KABLAMMO - Realistic Explosion FX - Syndicate Distracto-tones
say_channel - Say channel datums govern the dissemination of messages to registered listen input module datums. In its simplest form, this
involves a say message datum being passed from an output module to a channel, and the channel then performing shared input
formatting before passing the say message to registered listen modules. Say channels also determine whether a message should
be affected by output and input modifiers, and whether the sender should display a speech bubble and play a speech sound.
delimited - Delimited say channel datums, by some criteria, restrict the number of listeners that a say message is passed to. This typically
manifests as only sending messages to listeners within a range of the speaker, or only sending messages to listeners registered
to a specific subchannel. A global say channel datum may be associated with a delimited channel, which will receive all messages
sent over the delimited channel and in turn may send messages to all listeners. See /datum/say_channel/global_channel.
bundled - Bundled say channels are a form of delimited channel that restrict the number of listeners that a say message is passed to on
the basis of which subchannel a listener is registered to. Unlike say channel IDs, subchannel IDs may be defined arbitrarily at
runtime; subchannel IDs are commonly BYOND atom references to some shared datum among listeners.
local - Local say channels are a form of delimited channel that restrict the number of listeners that a say message is passed to on the
basis of range. How this range is calculated may be altered by overriding GetAtomListeners().
global_channel - Global say channel datums act as optional parters to delimited say channels, with the delimited channel passing all messages
sent over it, irrespective of subchannel or range, to the global channel. In turn, any message sent to the global channel will
be sent to all listeners on the delimited channel, irrespective of subchannel or range.
say_message - The base message type; it contains the content of a message and all of the relevant metadata. Any text that has been passed
to say() is in turn passed into a new say message datum.
shared_input_format_module - Shared input format modules correspond to a listen input module, and handle all shared processing for it. Prior to passing a
say message datum to individual inputs, a say channel will group inputs by type, and apply shared processing defined in a
shared input format module once, if it exists. This mitigates the need for input modules to perform redundant processing.
state_based - For commands with multiple states (several stages of entering inputs, confirmation dialogs etc.).
Define a proc for each state and use go_to_state(new_state) to go to that state. When the
user inputs their next command instead of being processed by the Spacebee extension system it will
get processed by said state of this command.
confirmation - For dangerous commands that the user should really doublecheck. Override
prepare to check the validity of the vars and return a message (or null to cancel).
User will need to reply with ;;yes to continue at which point do_it gets called.
spectro_analysis - Analysis datum for the spectrometer
speech_manager - Global manager for speech systems. Used for module lookup, language lookup, and sayflag message modifier processing.
speech_module - Speech module datums serve as a parent type for speech outputs and speech modifiers, which exist to modify and format say
message datums passed to them from a speech module tree.
modifier - Speech modifier module datums exist to modify and format say message datums passed to them by a speech module tree.
output - Speech output module datums modify say message datums passed to them from a speech module tree, then in turn pass the message
to a say channel datum.
bundled - Bundled speech output module datums operate in a similar manner to ordinary speech outputs, however instead of sending a say
message datum to an ordinary say channel, they pass it to a specific subchannel of a bundled say channel.
prefix - Speech prefix modules handle any operations associated with a specific message prefix or prefixes. Messages with a prefix
will attempt to use the prefix module with the longest matching ID; a message with a prefix of ":lhtest" will attempt to
use the ":lh" prefix module, and only if incompatible will use the ":" prefix module.
postmodifier - Postmodifier prefix modules handle prefix operations that should occur after module processing effects.
premodifier - Premodifier prefix modules handle prefix operations that should occur prior to module processing effects.
channel - Channel prefix modules are modules that handle prefixes that attempt to divert a message from its original say channel to
another say channel.
speech_module_tree - Speech module tree datums handle applying the effects of speech prefix, modifier, and output modules to say message
datums sent by the parent atom. All say message datums will be processed here prior to being passed to the appropriate
say channel by a speech output module.
auxiliary - Auxiliary speech module tree datums handle adding and removing their own modules to a specified target speech module
tree, and transferring modules when the target changes. These are used as speech module trees for datums that
frequently change between atoms with their own trees, such as clients or minds.
statusEffect - Our datum that keeps track of an individual status effect.
Speed regeneration - changeling speedregen status effect
Arc Flash - Ranged chain lightning attack. Bounces between up to chain_count extra mobs within chain_range tiles of the initial target.
Discharge - Melee attack. Shocks a targeted mob, or can be used on an airlock to temporarily cut its power.
Flash - Super simple CC. Short-ranged elecflash.
Jamming Field - Makes the user functions as a radio jammer for the duration. Functions by applying a status effect with a visible aura.
Jolt - Killing skill that does decent damage even when it doesn't finish.
The final tick stops the target's heart (or can restart it if they have SMES human.)
Use time is instant if the user jolts themselves.
Polarize - Applies a magnetic aura to nearby humans, as with the bio-magnetic fields random event. All auras will be of the same polarity.
Sap Power - Arcfiend's main way of obtaining power for their abilities.
Can be used on:
Ride the Lightning - This ability lets arcfiends travel through power cables like a Voltron (hence the type name).
Each tile traveled costs 3 units of power.
tgs_chat_command - User definable chat command. This abstract version MUST be overridden to be used.
tgs_chat_embed
field - See https://discord.com/developers/docs/resources/message#embed-object-embed-field-structure for details.
footer - See https://discord.com/developers/docs/resources/message#embed-object-embed-footer-structure for details.
media - Common datum for similar Discord embed medias.
provider - See https://discord.com/developers/docs/resources/message#embed-object-embed-provider-structure for details.
author - See https://discord.com/developers/docs/resources/message#embed-object-embed-author-structure for details. Must have name set in New().
structure - User definable chat embed. Currently mirrors Discord chat embeds. See https://discord.com/developers/docs/resources/message#embed-object for details.
tgui_color_picker - Datum used for instantiating and using a TGUI-controlled color picker.
async tgui_color_picker - An asynchronous version of tgui_color_picker to be used with callbacks instead of waiting on user responses.
tgui_input_bitfield - Datum used for instantiating and using a TGUI-controlled bitfield editor.
async tgui_input_bitfield - An asynchronous version of tgui_input_bitfield to be used with callbacks instead of waiting on user responses.
tgui_input_number - Datum used for instantiating and using a TGUI-controlled numbox that prompts the user with
a message and has an input for text entry.
async tgui_input_number - An asynchronous version of tgui_input_number to be used with callbacks instead of waiting on user responses.
tgui_input_pin - Datum used for instantiating and using a TGUI-controlled pin keyboard that prompts the user with
a message and has an input for pin entry.
async tgui_input_pin - An asynchronous version of tgui_input_pin to be used with callbacks instead of waiting on user responses.
tgui_input_text - Datum used for instantiating and using a TGUI-controlled textbox that prompts the user with
a message and has an input for text entry.
async tgui_input_text - An asynchronous version of tgui_input_text to be used with callbacks instead of waiting on user responses.
tgui_message - Datum used for instantiating and using a TGUI-controlled simple message box
tgui_modal - Datum used for instantiating and using a TGUI-controlled modal that prompts the user with
a message and has items for responses.
tgui_modal/list_input - Datum used for instantiating and using a TGUI-controlled list input that prompts the user with
a message and shows a list of selectable options
async tgui_modal/list_input - An asynchronous version of tgui_modal/list_input to be used with callbacks instead of waiting on user responses.
tgui_window - Copyright (c) 2020 Aleksej Komarov
SPDX-License-Identifier: MIT
deletion_regressions - This is for regression tests of deletions that used to runtime.
This would ideally be replaced by Del The World, unit testing every single deletion.
unlockable_flock_structure - Subclass this for every new building type you add
Override the check_unlocked() function to do whatever unlock logic you have
If you're looking for a specific event, I recommend /datum/flock.hasAchieved()
image/maptext - Maptext images are special subtypes of images without an icon with the sole purpose of displaying maptext to a single client.
Maptext images should never be instantiated directly using new; use the NEW_MAPTEXT macro instead.
ion trails - ///// Attach an Ion trail to any object, that spawns when it moves (like for the jetpack)
just pass in the object to attach it to in set_up
Then do start() to start it and stop() to stop it, obviously
and don't call start() in a loop that will be repeated otherwise it'll get spammed!
Detonator Assembly - The holder of the canbomb assembly which we use to handle the wires and functions of the canbomb.
Maybe once we have some kind of wire hacking component we could do away with this and merge that whole shitshow into obj/item/assembly
spawnable - A type to allow you to spawn custom wigs from the map editor
random - Randomized wig for the cargo crate
mask/cursed clown mask - Cluwne
shoes/sandal/magic/wizard - Subtype that wizards spawn with, and is in their vendor. Cows can wear them, unlike regular sandals (might also be useful in the future)
mini neutron-crossbow - Crossbow that fires irradiating neutron projectiles like the nuclear reactor
DEBUG ITEM - don't actually use this for things. Unless you really want to, or it might be funny.
laser assault rifle - nanotrasen gun
owl gun - modular components - putting them here so it's easier to work on for now////////
////////////////////////////Owl Gun
YOU SHOULDN'T SEE THIS - TELL A CODER - Abstract supertype for implants that do something explodey-ish when you die. Includes functionality for scaling with implant number
tail - Severed tail images go in 'icons/obj/organ/tail.dmi'
on-mob tail images are defined by organ_image_icon
both severed and on-mob tail icon_states are defined by just icon_state
try to keep the names the same, or everything breaks
ptl_seller - This is a stupid singleton laser sink that exists so that lasers that hit the edge of the z-level have something to connect to
lattice - metal beam lattices for connecting station parts.
auto - lattice spawners, for mapping large quantities of lattice at once.
They auto connect in four directions depending on the lattices around them, plus you can set them to connect to certain turfs.
turf_attaching - connect to all non turf/space turfs
wall_attaching - connect to all simulated and unsimulated walls
barricade - literally only used in 'assets/maps/prefabs/prefab_water_honk.dmm' Why not just use a girder?
directional_icons - a lattice that starts off with icon_state "lattice-dir"
directional_icons_alt - a lattice that starts off with icon_state "lattice-dir-b"
atmospherics - Quick overview:
Pipes combine to form pipelines.
Pipelines and other atmospheric objects combine to form pipe_networks.
Note: A single pipe_network represents a completely open space.
Pipes -> Pipelines
Pipelines + Other Objects -> Pipe network
Clothing Booth - A vendor for purchasing clothing items using a TGUI interface that (should) allow for the easy navigation of an otherwise large pile of available
stock.
Primary Siphon Control - manual control panel for core operation of siphon itself (raising and lowering, on and off); stays physically paired to the siphon
meat/FreshFlesh - This is currently unused as it was intended for use in PR 6684, but it was removed upon request. This might be a temporary removal, so it's staying here.
Station Map - Minimap objects are responsible for displaying and handling player interaction with minimaps. They act as the physical
manifestation of minimap datums, being displayed either on the map or in a UI element.
Alert Map - Alert Minimap
Map Controller - Minimap controllers are responsible for handling player manipulation of minimaps, including panning and zooming the map,
managing minimap marker visibility, and creating and deleting markers.
barrel_embers - firey embers, for use with burning_barrel
bloody_aura - Used for bloodlings, maybe would be cool for other stuff!
petals - Used for Lavender reagent
plain_data - Data type for storing just data, without any procs or other fanciness. Meant to be used instead of deeply nested lists for e.g. TGUI ui_data.
procpath - Type used to sanely access vars on a proc.
Example: