Shiptest 13 - Modules - Types


/proc/getFlatIcon Create a single /icon from a given /atom or /image.
/proc/generate_icon_alpha_mask Helper proc to generate a cutout alpha mask out of an icon.
/proc/generate_and_hash_rsc_file generates a filename for a given asset. like generate_asset_name(), except returns the rsc reference and the rsc file hash as well as the asset name (sans extension) used so that certain asset files dont have to be hashed twice
/proc/generate_asset_name Generate a filename for this asset The same asset will always lead to the same asset name (Generated names do not include file extention.)
/proc/icon2base64 Converts an icon to base64. Operates by putting the icon in the iconCache savefile, exporting it as text, and then parsing the base64 from that. (This relies on byond automatically storing icons in savefiles as base64)
/proc/is_valid_dmi_file given a text string, returns whether it is a valid dmi icons folder path
/proc/get_icon_dmi_path given an icon object, dmi file path, or atom/image/mutable_appearance, attempts to find and return an associated dmi file path. a weird quirk about dm is that /icon objects represent both compile-time or dynamic icons in the rsc, but stringifying rsc references returns a dmi file path ONLY if that icon represents a completely unchanged dmi file from when the game was compiled. so if the given object is associated with an icon that was in the rsc when the game was compiled, this returns a path. otherwise it returns ""
/proc/icon2html the dmi file path we attempt to return if the given object argument is associated with a stringifiable icon if successful, this looks like "icons/path/to/dmi_file.dmi" but they pass both isicon() and isfile() checks. theyre the easiest case since stringifying them gives us the path we want generate an asset for the given icon or the icon of the given appearance for [thing], and send it to any clients in target. Arguments: