Is manifest.json a known format ?

[bratch9]

As title, is the manifest.json a format that we know the tags for ? ( Or can it be documented ? )

Looking at my extension that lives on both Forge and DMsGuild and how best to keep them in sync, and possibly a batch file to 'collect' my owned DMsGuild extensions/mods into a DMsGuild.dat vault file for quick update.

By inspection the vault dat layout looks simple, just missing information on the manifest.json. ( Guessing a version number, maybe a name/description, and a list of files ? )

-pete

[Moon Wizard]

You should not be using the manifest.json for any purpose of your own. It is purely an internal file used by our update system to help manage product delivery.

Regards,
JPG

[bratch9]

You should not be using the manifest.json for any purpose of your own. It is purely an internal file used by our update system to help manage product delivery.

Regards,
JPG

Did some play and you don't need a manifest.json file in a vault.dat file for the items to show up in FG. ( Was assuming I would need it. )

It does not seem to support zip files in the vault.dat file (zip), but that is ok for me I can unpack the extensions into files before making the combined zip vault.dat file.

So I can now batch dump my DMsGuild extensions into a single .dat file.

It does seem to 'delete' this unknown file on an update, but a quick 'read only' tick on the file stops this.

Do you see any 'issues' that this might cause ?

Thanks,
-Pete

[Moon Wizard]

I'm concerned about the fact that you are jamming this functionality into a system that it's not designed for, and that it could negatively impact both yourself and other users either now or in the future when things don't work right...

Regards,
JPG

[bratch9]

I'm concerned about the fact that you are jamming this functionality into a system that it's not designed for, and that it could negatively impact both yourself and other users either now or in the future when things don't work right...

Regards,
JPG

Issue noted..

Would it be complex to add a concept of a second vault style location. Say a 'user' folder that just pulls the zip file(s) into the system virtual file system mapping much the same way as the vault. But known about so it does not try and look for a manifest.json by the updater ( which might later cause crash issues as my zip/dat file does not have one. ), and does not delete them on update ?

If you think this is simple, I'll look to add it to the 'wish' list. ( Otherwise I'll take the risk that it might stop working at some point.. )

Thanks for your feedback,
-pete

[Moon Wizard]

You're welcome to add to the wish list; but I think you're trying to make this too complex. Users can already add modules/extensions/rulesets/images directly to their data folder...

Regards,
JPG

[bratch9]

You're welcome to add to the wish list; but I think you're trying to make this too complex. Users can already add modules/extensions/rulesets/images directly to their data folder...

Regards,
JPG

You seriously think I don't know users can add to modules/extension data folder !

The issue I have is having to keep things up to date, the number of times we have to re-start the server because we forgot/failed to update correctly is what I'm trying to avoid.

For example,

Lets say I dump over the DMsGuild extension into the FG/extensions folder, but I've not noticed that ext_v1.ext has been renamed ext_v2.ext. ( Because who checks and knows exact version numbers in use.. ) Due to how the 'extensionstate.xml' references the filename, the campaign will pick up the old 'ext_v1.ext' and list this at the top group now, with the ext_v2.ext been listed way down the list. Possibly missed realising its not selected the new version.

I've see forge updates have _v[n] number updates, causing 'mess' of old version still in the extensions folder. ( I reported this to the owner, and they swapped to keeping the extension name consisted between updates. )

But conflicts do happen, and it takes time to resolve.

Having a quick batch file that packs the DMsGuild extensions into a single zip that FG uses, makes for quick swift updates with known good extensions. ( But you still have to deal with name changes as now a renamed extension filename might not exist so the campaign start might be 'missing' an extension. This is rare, but it happens. )

And other possible, rare situation example,

1. 'bob' creates a forge coin extension, marks it as 'live' and up loads 'coin.ext'
2. 'tom' creates a forge coin extension, marks it as 'live' and up loads 'coin.ext'

Because these are in the 'live' setting the 'vault' gets the files,
1. bob-uuid.dat ( which contains bob coin.ext code )
2. tom-uuid.dat ( which contains tom coin.ext code )
3. FG can see 'bob coin' and 'tom coin' extension and I can pick which I want to use.

If these were marked for 'data', this would cause a file overwrite and only one extension would exist on my machine. But since I did not know what 'files' are in these forge items, I can not tell what 'conflicts' this might cause. I might already have a forum based coin.ext in my extension folder that will be overwritten. I might be thinking why am I missing a purchase ?

These are 'rare' events, but they make a point that conflicts can/do/will happen. All I want to do is avoid them as much as possible.

A suggestion would be to use 'live' and 'data' forge options to just select 'password' or 'no password' and store the forge items always in the vault. Since you name official modules these do not conflict in the vault, and the forge items are uuid names and will not conflict. This allows for a know purchase to always exist and not cause possible conflicts in the FG/extension folder, no matter what a 'developer' names the file(s).

But like you said 'USERS' own the fg/extension/module/tokens folder, so I see no reason why FG should dump purchases into these folders and possible cause conflicts/overwrites. It would also solve forge rename issues because it would just live in the 'uuid.dat' vault file which would be replaced and tidy up the old versions etc.

But knowing that FG users also use DMsGuild extensions/modules having a 'clean' way to keep those up to date would be nice. Hence my search into a DMsGuild.dat vault batch file.

This is the 'workshop' to allow us to talk about issues and how they might be resolved as the a step to improving FG ?

( I know you love a wall of text... )

-pete

[Moon Wizard]

To be fair, I usually just scan walls of text. Too much to do. :)

I'm just saying that this particular issue and use case is very limited, and creating complex solutions can sometimes be more maintenance than just keeping track manually.

Regards,
JPG