emotracker-documentation

discord is not documentation

Project maintained by Xkeeper0 Hosted on GitHub Pages — Theme by mattgraham

Unsorted garbage from Discord

Notes on things that might be useful and aren’t yet split into different sections.

Hi folks - sorry for the ping, but a friendly reminder has become necessary. When you have a question, check faq first, then at least make a cursory attempt at searching the support channels. The number of times recently that somebody has asked a question directly answered by faq AND answered 5 minutes prior by somebody in a support channel is out of control. If it continues to get worse, I’m going to have start doing something more direct to keep the channels clean and useful, and I’d rather not do that.

no way to prevent this, says every discord where this happens

Development

You are expected to reverse-engineer the way that EmoTracker works via looking at the ALTTPR tracker source.

This package source is provided for use as reference by all EmoTracker pack developers. I do not provide any support for working with this source beyond discussions in the EmoTracker Discord, and I do not accept merge requests.

in what is likely a shocking surprise to nobody on the planet, this package does not implement the “Package Documentation” feature of EmoTracker. lol. of course.

Random stuff

Undocumented command line option: -dev

If you create your own shortcut for EmoTracker, you can add the -dev command line argument. That will cause the entire app to use <user>/EmoTracker/dev instead of /EmoTracker for all relevant directories (edited)

something regarding location accessibility updates

There is caching within a single logic update now if you set "enable_accessibility_rule_caching": true in your pack's settings, but you are correct that each user operation minimally results in one full re-evaluation. (edited)

rather than actually providing documentation, let’s get mad at people trying to figure out how things work

Here's what I believe to be the full extent of the accessibility rule syntax: rule = baseRule | inspectable inspectable = "{", baseRule, "}" baseRule = [clause], { ",", clause } clause = [whitespace], (sequenceBreakable | glitchable | counted), [whitespace] sequenceBreakable = "[", counted, "]" glitchable = "[", "[", counted, "]", "]" counted = code, [ ":", integer ] code = item | lua | location item = identifier lua = "$", identifier, { "|", identifier } location = "@", identifier, ["/", identifier] identifier = <any character> integer = <you know what this is> whitespace = " " | "\t" | "\n" </pre>

wow, thanks. anyway,

EmoSaru 2021-11-28 21:42
Okay, I’m really not particularly interested in defining a formal grammar here. It’s an ad hoc parser implementation, and this really isn’t relevant to what more or less anybody here is doing.

knowing how things work is not relevant to what anybody is doing 👍

Pinned Messages

All of the notes in this section are copied from pinned messages.

outside of those channels:

Customizations load order

Overrides replace the original file when loading, and need to be complete. Variants work the same, are still loaded by the variant path (relative to the override directory) and must be overridden independently from the default.

The loading priority order is:

  1. Variant Override
  2. Variant
  3. Override
  4. Default

Layouts and arrangement

[12:08 PM] Dorkmaster Flek: Mmm is vertical orientation like that a core app feature? I thought I recall seeing something like that in one of the menus...
[12:08 PM] Dorkmaster Flek: I could be misremembering that.

[12:08 PM] EmoSaru: Look at my pack.
[12:08 PM] EmoSaru: It's based on the layout names you provide.

Reserved names

The reserved layout names are:

tracker_broadcast
tracker_default
tracker_horizontal
tracker_vertical
tracker_capture_item

Image Filters and Mods

[10:08 AM] EmoSaru: I thought I had it listed somewhere in the schemas, but apparently I don't. I will figure out a place to put it, but here is the current list...

if only there was somewhere it could go

Filters can be applied in sequence by using a comma-separated list, and they apply in the order specified. Ex. “grayscale,brightness|0.5”

Custom Items

As of the latest EmoTracker version 2.3.5.0, it is now possible to implement custom items in Lua. This can be very powerful for certain advanced types of trackers.

You can find reference/example code here: https://emotracker.net/developers/sdk/emotracker_sdk.zip

whatever this is

To help address issues like this, I’ve added JSON schemas for the most critical JSON formats used by EmoTracker. You can find them on the web here…

There is also a composite schema available at https://emotracker.net/developers/schemas/all.json but it requires a certain amount of context to exist in the file before it can reliably determine which type of data you are editing.

If you are using VS Code and have organized your json files sensibly, you may find that this addition to your workspace’s settings.json will work for you. Feel free to adapt it to your directory structure.

"json.schemas": [
    {
        "fileMatch": [
            "*/items/*.json",
            "*/*.items.json",
        ],
        "url": "https://emotracker.net/developers/schemas/items.json"
    },
    {
        "fileMatch": [
            "*/layouts/*.json",
            "*/*.layouts.json",
        ],
        "url": "https://emotracker.net/developers/schemas/layouts.json"
    },
    {
        "fileMatch": [
            "*/locations/*.json",
            "*/*.locations.json"
        ],
        "url": "https://emotracker.net/developers/schemas/locations.json"
    }                                   
]

I can’t guarantee that these are 100% perfect right now, but I will attempt to keep them updated as changes happen.