Files
Bubberstation/code/modules/mapping
Leland Kemble 348789fa8d The Renamening- upgrades UNIQUE_RENAME and moves a lot of renaming implementations under it (#93115)
## About The Pull Request

Moves a lot of the unique renaming implementations described in #82664
to the functions given by the `obj_flag` `UNIQUE_RENAME`.
`UNIQUE_RENAME` has been given new properties to account for
non-standard renaming, these being the `RENAME_NO_DESC` flag that
prevents changing the description, the `nameformat()` and `descformat()`
procs that, when modified, allow for applying naming formats(i.e. "Body
Bag - [input]"), as well as other post-renaming handling such as
changing the name of the output plant of a renamed seed, the
`rename_checks()` proc that allows for unique naming prevention(such as
a locked personal closet), and the `rename_reset()` proc to clean up
other possible renamed variables potentially changed in `nameformat()`
and `descformat()`.

This also adds `/datum/element/tool_renaming` to crayons, which will let
them rename anything that has `UNIQUE_RENAME`. I looked through
everything with that flag, and I didn't see anything that I don't think
should be renameable by a crayon(except things that shouldn't be
renamable with pens), so it shouldn't fuck anything up.

## Why It's Good For The Game

moves all of the non-honorable mentions in #82664 to the same renaming
system, and also moves all of the honorable mentions save for:

- plaques, as they only get renamed once and wouldn't benefit from
`UNIQUE_RENAME` imo
- books, because they're far more than just renaming, and are persistent
- paintings, because they're persistent
- photos, because they're not normal renaming and they're persistent
- endoskeletons, because they're done with a multitool in UI
- cardboard IDs, because they're far more than just renaming

Additionally, this fixes:

- Implanter renaming didn't work because a ! was missing
- Clown borg picket sign renaming didn't work because they didn't use
the correct arguments

This'll make it easier to make renameable objects in the future, as
well.

## Changelog
🆑

fix: fixes implanter renaming not working
fix: fixes clownborg picket sign renaming not working
code: brought most unique renaming implementations under UNIQUE_RENAME

/🆑
2025-10-17 01:56:09 +02:00
..

The code in this module originally evolved from dmm_suite and has since been
specialized for SS13 and otherwise tweaked to fit /tg/station's needs.

dmm_suite version 1.0
	Released January 30th, 2011.

NOTE: Map saving functionality removed

defines the object /dmm_suite
	- Provides the proc load_map()
		- Loads the specified map file onto the specified z-level.
	- provides the proc write_map()
		- Returns a text string of the map in dmm format
			ready for output to a file.
	- provides the proc save_map()
		- Returns a .dmm file if map is saved
		- Returns FALSE if map fails to save

The dmm_suite provides saving and loading of map files in BYOND's native DMM map
format. It approximates the map saving and loading processes of the Dream Maker
and Dream Seeker programs so as to allow editing, saving, and loading of maps at
runtime.

------------------------

To save a map at runtime, create an instance of /dmm_suite, and then call
write_map(), which accepts three arguments:
	- A turf representing one corner of a three dimensional grid (Required).
	- Another turf representing the other corner of the same grid (Required).
	- Any, or a combination, of several bit flags (Optional, see documentation).

The order in which the turfs are supplied does not matter, the /dmm_writer will
determine the grid containing both, in much the same way as DM's block() function.
write_map() will then return a string representing the saved map in dmm format;
this string can then be saved to a file, or used for any other purose.

------------------------

To load a map at runtime, create an instance of /dmm_suite, and then call load_map(),
which accepts two arguments:
	- A .dmm file to load (Required).
	- A number representing the z-level on which to start loading the map (Optional).

The /dmm_suite will load the map file starting on the specified z-level. If no
z-level	was specified, world.maxz will be increased so as to fit the map. Note
that if you wish to load a map onto a z-level that already has objects on it,
you will have to handle the removal of those objects. Otherwise the new map will
simply load the new objects on top of the old ones.

Also note that all type paths specified in the .dmm file must exist in the world's
code, and that the /dmm_reader trusts that files to be loaded are in fact valid
.dmm files. Errors in the .dmm format will cause runtime errors.