| /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: |
|---|
