- Instead of using expensive getFlatIcon() calls, character previews are now shown using screen objects in a second map window.
- Edited skin to add a named window for preferences setup that contains a browser plus a new map window to show the previews.
- Mannequins are still generated the same way, but now a MA is applied to four screen objects which are shown in the second map window.
- The screen objects are deleted on close of the preferences window. So we do make sure to close it when spawning.
So you can customize your character with tattoos or fur colors for Taj or whatever. I'll let Anewbe work out what he wants to whitelist other than what I did already.
The icons are sliced up with the HumanScissors program I wrote, so they are per-organ. So, lop off a limb, put it on someone else, they have the tattoos and whatnot. It's part of DNA so it comes with when cloning.
They are defined in the normal sprite_accessories file and the icons are all in markings.dm in the format of "markingname-organtag" so if you have a marking that spans both arms and torso you need "thatone-torso", "thatone-l_arm", "thatone-r_arm" icon states.
So you can customize your character with tattoos or fur colors for Taj or whatever. I'll let Anewbe work out what he wants to whitelist other than what I did already.
The icons are sliced up with the HumanScissors program I wrote, so they are per-organ. So, lop off a limb, put it on someone else, they have the tattoos and whatnot. It's part of DNA so it comes with when cloning.
They are defined in the normal sprite_accessories file and the icons are all in markings.dm in the format of "markingname-organtag" so if you have a marking that spans both arms and torso you need "thatone-torso", "thatone-l_arm", "thatone-r_arm" icon states.
Cyborgs have their minimum be equal to their species' minimum, and maximum be their species maximum plus twenty years.
Posibrains have a minimum of 1, and a maximum of 220, as discussed by EmperorJon.
Digital brains (drones) have a minimum of 1 and maximum of 150, as discussed by Spookerton.
* The /datum/category_item/player_setup_item datums did a good job of organizing the code for loading/saving/editing preferences data, but all of the code that applies preferences to newly created player mobs was still in a single function.
* This change adds a new proc to player_setup_item datums: copy_to_mob() which is called from the traditional copy_to() proc, allowing each preferences datum to apply its own character data to the mob.
* This allowes new preferences to easily compartmentalize their new code.
* I also moved all the code for existing preferences from copy_to() into the copy_to_mob() on their respective preferences datums.
The purpose is to ensure that new preferences that are in neither list get the appropriate enabled/disabled setting without having to utilize the savefile update path.
Also attempts to optimize the acquirement of the preference mob.
For reasons unbeknown to me, the client var is reset when the client logs outs and thus the preference mob cease to be.
Now stores the client key, and acquires the appropriate mob based on that, if possible.
Also removes the sanitation check because the holder isn't set before the preferences are created.
Fixes#12341.
Adds client verb to access the character setup screen from anywhere.
Moves name validation to species level, making it possible for IPCs to have numbers in their name.
Adds gender validation, also adds support to add neuter/plural genders in the future if ever desired.
Now sanitizes preferences before applying them to a mob.
Fixes#11433.
(cherry picked from commit e40246e9dfc9feb28b8c5a0a7ce765fd063c4f7e)
Begins breaking down the large character setup in more manageable modules, allowing for easier additions, edits, and removals.
(cherry picked from commit e116721977)
Conflicts:
code/modules/client/preferences.dm
code/modules/client/preferences_savefile.dm
polaris.dme
