Asset sync not updating scene background/foreground to local files

Hello,

I’m very new to the forge and am eagerly exploring it. One feature that is very important to me is portability. Likewise, I was thrilled to see the Asset Sync feature. It seems to work great, but after a seemingly successful run the webp images in my scene backgrounds/foregrounds are still listed as hosted on the assets.forge-vtt.com server.

Is this a bug or am I misunderstanding how this feature works?

Hey there :wave:

We’ve recently released a version bump that fixes a lot of issues in the assets sync (particularly in v11).

Could I ask you to please ensure that you are running Version 1.14.2, and that the run has the Update Foundry World selected.

image

If you’re still encountering the issue, there may be two explanations that I can think of:

  • The assets are hosted on a different Assets Library that doesn’t belong to the account you generated the API key from
  • There is an issue in the path to the data or the sync is not reading it properly.

If the assets and the API key both came from the same Forge account, it might be the latter. If so, could I please ask you to make an export of the scene’s JSON and share it here, so that I can have a look at the paths for the background and foreground? Thanks!

image

Thanks for the quick reply!

I can confirm that I am using the Forge module v1.14.2 and Foundry 11.307. The file is visible in my assets library, and when I run the sync it even downloads correctly. The only thing that’s missing is the path change in scene files.

Looking through the exported json, I see it’s a lot more than just the foreground/background that seems not to have been updated. I’ve linked the file here.

Thanks for providing the export! :slight_smile:

Just to double check, is the API key for the same account that the assets are stored in?

For example, if the world is a friend’s world and points to a friend’s Assets Library, the paths won’t be changed and you’ll receive a message like this

I’ve confirmed that when I point to that same image in my own assets library, it gets migrated to local and changes the path, so I don’t believe it is an issue in the module’s code.

image

You’ll note that the one that points to your Assets Library isn’t migrated.

One way you can check this is by opening the dev tools console with F12 and typing await ForgeAPI.getUserId()
image
For example, this is my personal assets library ID. If you type that, you should see 64d8dd.... If you could please post a screenshot, I’d appreciate it!

Thanks @phi! Here’s the screenshot:

I’ve not yet intereacted with another player, account, or API key in my forge account, so I’m reasonably sure the files are in my account.

Thanks for double checking it and providing the screenshot!
Ignore the previous version of this post which deals with world ids, I suspect I found what’s going wrong

Do you see any errors during the sync process in the notifications or in the dev tools console (F12) at all, such as

image

I’ve noticed that if there are assets that fail to sync down the update world to use local assets step may not complete.

Please let me know if this is what’s going on in your case! :pray:
So far that’s the only way I’ve been able to reproduce what you’re describing, but it would be very helpful to be sure, while we’re troubleshooting, so that I can nail it in the fix

Ah, that sounds plausibly like issue. I hadn’t spotted this error message before:

assets-sync.js:1246 Error migrating Scenes database :  TypeError: Cannot convert undefined or null to object
    at Function.keys (<anonymous>)
    at ActorDelta.updateSource (/Applications/Foundry%20Virtual%20Tabletop.app/Contents/Resources/app/common/abstract/data.mjs:394:17)
    at #updateField (/Applications/Foundry%20Virtual%20Tabletop.app/Contents/Resources/app/common/abstract/data.mjs:476:39)
    at #updateData (/Applications/Foundry%20Virtual%20Tabletop.app/Contents/Resources/app/common/abstract/data.mjs:446:24)
    at Token.updateSource (/Applications/Foundry%20Virtual%20Tabletop.app/Contents/Resources/app/common/abstract/data.mjs:402:28)
    at EmbeddedCollection._createOrUpdate (/Applications/Foundry%20Virtual%20Tabletop.app/Contents/Resources/app/common/abstract/embedded-collection.mjs:255:28)
    at EmbeddedCollection.update (/Applications/Foundry%20Virtual%20Tabletop.app/Contents/Resources/app/common/abstract/embedded-collection.mjs:233:12)
    at #updateField (/Applications/Foundry%20Virtual%20Tabletop.app/Contents/Resources/app/common/abstract/data.mjs:470:31)
    at #updateData (/Applications/Foundry%20Virtual%20Tabletop.app/Contents/Resources/app/common/abstract/data.mjs:446:24)
    at Scene.updateSource (/Applications/Foundry%20Virtual%20Tabletop.app/Contents/Resources/app/common/abstract/data.mjs:402:28)

I’m getting this error with no other modules active. Let me know if I can help debug/troubleshoot further.

Thanks a bunch, I’m sure that’s what we’re running into! The error message indicates a failure to update the scene database, which explains why the changes that the asset sync is making are not reflected after the sync.

Unfortunately, it looks like the refusal to update is actually coming from Foundry’s side there, and it’s because of malformed data on one or more of the a scene’s embedded tokens’ deltas (variation from the original actor, in the scene).

The rabbit hole goes quite deep in this, but I’ve attempted to reproduce that error to no avail, even with the export of that scene. If it is only a single scene that’s failing to sync to update its image values, it is possibly due to something in the embedded tokens in the scene data, or different behaviour with different Foundry versions (for reference, I am testing on 11.307)

From my tests, I can’t see that this is coming from the asset sync but rather the embedded scene data, but if it’s something subtle on our side we’d definitely want to find it. The trouble is that I can’t seem to replicate that behaviour. We pass the embedded entities to Foundry as is, changing only specific fields that reference Assets Library content, so an embedded document that we don’t touch but has an issue may still cause the migration to fail.

If you’re willing, could I please ask you to create a ticket in the #ticket-support channel of the Forge Discord, where you would be able to privately share an export of your world with us (or a link to a zip that contains it), as that should be a way to replicate that behaviour on our side.

Thanks @phi! I’ve posted my world export as you’ve suggested to a Discord ticket.

1 Like