84dc5535dc
* These two are easy * !!!runlevel_flags the fact it was global.runlevel_flags.len has me a bit...iffy on this. * !!!json_cache Same as above. used global. * player_list & observer_mob_list * mechas_list * this wasn't even used * surgery_steps * event_triggers * landmarks_list * dead_mob_list * living_mob_list * ai_list * cable_list * cleanbot_reserved_turfs * listening_objects * silicon_mob_list * human_mob_list * Update global_lists.dm * joblist * mob_list * Update global_lists.dm * holomap_markers * mapping_units * mapping_beacons * hair_styles_list * facial_hair_styles_list * Update global_lists.dm * facial_hair_styles_male_list * facial_hair_styles_female_list * body_marking_styles_list * body_marking_nopersist_list * ear_styles_list * hair_styles_male_list * tail_styles_list * wing_styles_list * escape_list & rune_list & endgame_exits these were all really small * endgame_safespawns * stool_cache * emotes_by_key * random_maps & map_count * item_tf_spawnpoints * narsie_list * active_radio_jammers * unused * paikeys * pai_software_by_key & default_pai_software * plant_seed_sprites * magazine_icondata_keys & magazine_icondata_states * unused * ashtray_cache * light_type_cache * HOLIDAY!!! this one was annoying * faction stuff (red?!) * Update preferences_factions.dm * vs edit removal * backbaglist, pdachoicelist, exclude_jobs * item_digestion_blacklist, edible_tech, blacklisted_artifact_effect, selectable_footstep, hexNums, syndicate_access * string_slot_flags and hexdigits->hexNums * possible_changeling_IDs * vr_mob_tf_options * vr_mob_spawner_options * pipe_colors * vr_mob_spawner_options * common_tools * newscaster_standard_feeds * Update periodic_news.dm * changeling_fabricated_clothing * semirandom_mob_spawner_decisions * id_card_states * Update syndicate_ids.dm * overlay_cache & gear_distributed_to * more * radio_channels_by_freq * Update global_lists.dm * proper * default_medbay_channels & default_internal_channels default_internal_channels is weird as it has a mapbased proc() but that proc is never called... * valid_ringtones * move this * possible_plants * more * separate these moves xeno2chemlist from a hook to a new global list. * tube_dir_list * valid_bloodreagents & monitor_states * Junk * valid_bloodtypes * breach_burn_descriptors & burn * more!! appliance_available_recipes seems uber cursed, re-look at later * Appliance code is cursed * wide_chassis & flying_chassis * allows_eye_color * all_tooltip_styles * direction_table * gun_choices * severity_to_string * old event_viruses * description_icons * MOVE_KEY_MAPPINGS * more more * pai & robot modules * Update global_lists.dm * GEOSAMPLES Also swaps a .len to LAZYLEN() * shieldgens * reagent recipies * global ammo types * rad collector * old file and unused global * nif_look_messages * FESH * nifsoft * chamelion * the death of sortAtom * globulins * lazylen that * Update global_lists.dm * LAZY * Theese too * quick fix --------- Co-authored-by: Kashargul <144968721+Kashargul@users.noreply.github.com>
In-code keypress handling system
This whole system is heavily based off of forum_account's keyboard library. Thanks to forum_account for saving the day, the library can be found here!
.dmf macros have some very serious shortcomings. For example, they do not allow reusing parts
of one macro in another, so giving cyborgs their own shortcuts to swap active module couldn't
inherit the movement that all mobs should have anyways. The webclient only supports one macro,
so having more than one was problematic. Additionally each keybind has to call an actual
verb, which meant a lot of hidden verbs that just call one other proc. Also our existing
macro was really bad and tied unrelated behavior into Northeast(), Southeast(), Northwest(),
and Southwest().
The basic premise of this system is to not screw with .dmf macro setup at all and handle
pressing those keys in the code instead. We have every key call client.keyDown()
or client.keyUp() with the pressed key as an argument. Certain keys get processed
directly by the client because they should be doable at any time, then we call
keyDown() or keyUp() on the client's holder and the client's mob's focus.
By default mob.focus is the mob itself, but you can set it to any datum to give control of a
client's keypresses to another object. This would be a good way to handle a menu or driving
a mech. You can also set it to null to disregard input from a certain user.
Movement is handled by having each client call client.keyLoop() every game tick.
As above, this calls holder and focus.keyLoop(). atom/movable/keyLoop() handles movement
Try to keep the calculations in this proc light. It runs every tick for every client after all!
You can also tell which keys are being held down now. Each client a list of keys pressed called
keys_held. Each entry is a key as a text string associated with the world.time when it was
pressed.
No client-set keybindings at this time, but it shouldn't be too hard if someone wants.
Notes about certain keys:
Tabhas client-sided behavior but acts normallyT,O, andMmove focus to the input when pressed. This fires the keyUp macro right away.\needs to be escaped in the dmf so any usage is\\
You cannot TICK_CHECK or check world.tick_usage inside of procs called by key down and up
events. They happen outside of a byond tick and have no meaning there. Key looping
works correctly since it's part of a subsystem, not direct input.