Custom token images

[digitalsadhu]

Is your feature request related to a problem? Please describe. Many people have requested we add the ability to specify custom token images. It's a very popular one.

Describe the solution you'd like It should be possible to somehow provide token images what will be used in place of the vector tokens we current draw. Token images of small size general do not display well so it may be best to limit these to gridsizes of at least 50+px It doesn't really work to allow tokens to be specified as URLs within the current URL (in the way background is currently specified) as this will result in massive unwieldy URLs.

Describe solutions you've considered Adding state to the map and tying things together with a session key where the key can be used to set token images that the map will use for that session.

URL shortning where token image URLs must be first given to a shortner which provides a small token that can be used in the URL

Adding a config file system where a user can define all sorts of config about how the map should look, upload it in maybe yaml or json format somewhere and then provide the config file to the map

[digitalsadhu]

Summary of Proposed approaches

Approach 1.

Build a portal to upload background images and tokens. Get an account id and feed that to otfbm to take advantage of uploaded content

Example:

otfbm.io/~swamp/b2-Urzer/a1-orc?id=a1b2c3d4

• swamp - name used to save bg in account
• id - account id

Approach 2.

Define a text based config file in some format (json, tank, custom, whatever?) upload it to somewhere accessible online and then feed it to otfbm to do complex setup

Example

Create a config file, something like config.txt

Urzer http://imgur/asd/barbarian.jpg
Orc# http://imgur/asd/orc.jpg

Upload somewhere, maybe discord or wherever.

Load the config file in the url

https://otfbm.io/a1-Urzer/b2-orc1/c3-orc3?config=http://mysite/config.json

Approach 3.

Assign users an id that they can use to set token images (and maybe other things?) in the map. This requires the map to hold state.

Example

https://otfbm.io/Urzer/a1b2c3d4e5
https://otfbm.io/orc1/a1b2c3d4e5
https://otfbm.io/orc2/a1b2c3d4e5
https://otfbm.io/a1-Urzer/b1-orc1/c1-orc2

Approach 4.

Use a separate URL to generate short codes for token image urls and have the users feed each one in.

Example

https://tokens.otfbm.io/https://imgur.com/asd/asd/sa/sad/ads/token.jpg

Responds with a code a1b2c3d4e5 that can be put in the URL.

https://otfbm.io/a1-Urzer-a1b2c3d4e5/b1-orc1-a1b2c3d4e5/c1-orc2-a1b2c3d4e5

[RCarretta]

Thoughts/pros/cons:

Approach 1. Build a portal to upload background images and tokens. Get an account id and feed that to otfbm to take advantage of uploaded content

Pro - very easy to set up the authentication bits. we can use cognito and dont need to worry about handling usernames/etc Pro - can tie this into social login very easily Con - need to build the web portal Con - will carry some additional maintenance cost for authentication/database/etc

Approach 2. Define a text based config file in some format (json, tank, custom, whatever?) upload it to somewhere accessible online and then feed it to otfbm to do complex setup

This approach makes sense to me if the entire state of the map can be imported/exported as JSON/YAML, for example. It doesn't make much sense (to me, at least) to allow some config to be imported this way but not have a unified story. If it is done in a unified way, we would support via URL config as well. Pro - Another way to set up maps. Could be unified so new config options could be represented as yaml/json easily before encoding as otherwise potentially obtuse URL parameters Con - Mostly for power users, which I think is not where OTFBM's problem mostly is. Doesn't help casual users basically at all. Con - User needs to find a place to host file (probably pastebin in most cases)

Approach 3. Assign users an id that they can use to set token images (and maybe other things?) in the map. This requires the map to hold state. Pro - Easy to understand. A URL/REST call edits the map, period. Con - Without session-based auth, anybody could edit any map. Avrae alias wont be able to do sessions. Basically relies on security through obscurity. Con - Takes OTFBM in an entirely other direction - requiring state for maps. It seems inevitable that we might eventually get there, but do we really want to take that step for token art of all things?

Approach 4. Use a separate URL to generate short codes for token image urls and have the users feed each one in. Pro - Much of this infra already in place from backgrounds Pro - Can be applied to any of the other approaches

[RCarretta]

After some discussion, have decided we will pursue a phase 1 of Approach 4 followed by a phase 2 of Approach 1.

[digitalsadhu]

Landed a phase 1 implementation in https://github.com/otfbm/maps/pull/14 and https://github.com/otfbm/maps/pull/15

[digitalsadhu]

Needs documentation #8