Support .meta.json

[LPGhatguy]

This is an alternative to init.model.json support (#114) and opens up a lot of neat features like allowing scripts to be disabled (#34) and giving us a place to stick metadata about uploaded assets (#41).

It'll look like a pared-down version of .model.json files, supporting just properties, and maybe asset-specific metadata:

{
    "properties": {
        "Disabled": {
            "Type": "Bool",
            "Value": true
        }
    },
    "uploadedAssetId": "12342124"
}

[jerrin-foster]

Any ETA yet? Really looking forward to this.

[LPGhatguy]

Shouldn't be hard to build out! I'm planning on getting to this within the next week or two.

[LPGhatguy]

I don't think this is quite done -- we still should consider having non-init .meta.json files for attaching metadata to existing instances.

This is a little trickier! For example, to attach metadata to foo.server.lua, do you name your meta file foo.meta.json? foo.server.lua.meta.json? What happens if there's also a foo.lua?

[osyrisrblx]

foo.server.meta.json?

[jerrin-foster]

As @osyrisrblx says, using an implied file ext would be better, but I'd suggest just keeping it as strict & simple as possible. Very few people will have a case wherein they have 2 different objects with the same name in the same location, so using the base name of the file should suffice.

(e.g. foo.meta.json should work for foo.lua, foo.server.lua, etc.)

[Kampfkarren]

As I said on Discord, implied filenames are the easiest, with an optional attribute in the meta.json file to specify what file you're talking about.