Sturmlilie/duyguji_preliminary

## duyguji_preliminary
Uncode emoji (separate mod): All of these have codepoints allocated by the Unicode Consortium, which don't have to be touched. For rendering, the existing resource pack infrastructure Mojang provides and which was recently updated to allow full UTF-16 (up to codepoint 0x10FFFF) fonts is used. Since the coverage between the existing permissively licensed emosets differs, the idea is to have multiple sets installed, each as one individual resource pack, (eg. one main and one for fallback) which are queried for glyphs in descending priority. The priority is to be configurable by the user in an approriate graphical interface.
Unfortunately there are some bugs in Mojangs code that have to be remidied for this to work correctly.

Custom emopacks (separate mod): One emopack (packaged as a single datapack) defines up to 256 emojis and is allocated exactly one unicode block in one of the two private use planes (0xFXXXX and 0x10XXXX). Since emojis can be part of persistent texts (nametags, signs etc.), the mapping of one emopack to a free block happens once and is henceforth serialized together with the savestate. Both mappings and textures should be downloaded by the client on demand; the information exchange on which resources to download / update happens at server join time. It is vital that once assigned blocks as well as codepoints **don't change** due to the persistent nature outlined above.
The user experience should be: As client, you install the appropriate mod and everything works. As server owner: You drop the datapack(s) of your choice into the appropriate folder of your world and everything works; even later removing and/or adding of new packs.

Item emojis (separate mod): As the server-owner, you should define which mods should be queried for items (since the list would get prohibitively large fast). Enough blocks covering all the items of the marked mods are allocated, and shortcodes are atuomatically generated based on the item identifiers (including collision resolution). In practice, as a user you should just be able to type :diamond: or :sakura_log: and have the item icons show up in your suggestion box like any regular emojis.

For all of the above: Users will always be able to define shortcode overrides locally if they so desire, so if someone doesn't like :tiny-potato: on a server sporting that emoji, they can rename it to :tater: without the server caring.
	Uncode emoji (separate mod): All of these have codepoints allocated by the Unicode Consortium, which don't have to be touched. For rendering, the existing resource pack infrastructure Mojang provides and which was recently updated to allow full UTF-16 (up to codepoint 0x10FFFF) fonts is used. Since the coverage between the existing permissively licensed emosets differs, the idea is to have multiple sets installed, each as one individual resource pack, (eg. one main and one for fallback) which are queried for glyphs in descending priority. The priority is to be configurable by the user in an approriate graphical interface.
	Unfortunately there are some bugs in Mojangs code that have to be remidied for this to work correctly.

	Custom emopacks (separate mod): One emopack (packaged as a single datapack) defines up to 256 emojis and is allocated exactly one unicode block in one of the two private use planes (0xFXXXX and 0x10XXXX). Since emojis can be part of persistent texts (nametags, signs etc.), the mapping of one emopack to a free block happens once and is henceforth serialized together with the savestate. Both mappings and textures should be downloaded by the client on demand; the information exchange on which resources to download / update happens at server join time. It is vital that once assigned blocks as well as codepoints don't change due to the persistent nature outlined above.
	The user experience should be: As client, you install the appropriate mod and everything works. As server owner: You drop the datapack(s) of your choice into the appropriate folder of your world and everything works; even later removing and/or adding of new packs.

	Item emojis (separate mod): As the server-owner, you should define which mods should be queried for items (since the list would get prohibitively large fast). Enough blocks covering all the items of the marked mods are allocated, and shortcodes are atuomatically generated based on the item identifiers (including collision resolution). In practice, as a user you should just be able to type :diamond: or :sakura_log: and have the item icons show up in your suggestion box like any regular emojis.

	For all of the above: Users will always be able to define shortcode overrides locally if they so desire, so if someone doesn't like :tiny-potato: on a server sporting that emoji, they can rename it to :tater: without the server caring.