search

4ian / GDevelop

🎮 Open-source, cross-platform 2D/3D/multiplayer game engine designed for everyone.
https://gdevelop.io
Other
11.24k stars 871 forks source link

GDevelop Cloud does not work with LDTK Tilemaps #4760

Open Silver-Streak opened 1 year ago

Silver-Streak commented 1 year ago

Describe the bug

The new LDTK map support does not work for cloud projects (Web or Desktop). The map file will load, but the resources won't load with it.

To Reproduce

Steps to reproduce the behavior:

  1. Create a new cloud project.
  2. Create a new LDTK Map file (or export one of the examples)
  3. Add a new Tilemap Object to the cloud project.
  4. Add the .ldtk file to the tilemap object.
  5. Add the Tilemap object to the scene.

The LDTK mapfile format does not embed tileset atlases. It just includes a relative path to the atlas file in the map json (https://ldtk.io/json/ > Tileset definition > relpath). My understanding is that with the LDTK implementation, as soon as you add the map file it pulls that relative path and also pulls in the atlas file.

My guess is that since that relative path isn't including the image file in the resources when it gets uploaded to the cloud, the atlas doesn't exist as far as the cloud is concerned (the path is invalid)

User DigitalRain experienced this using one of the example maps from LDTK, and here's the console error he got image Along with how it shows up in the editor: image

Local projects do add the resources correctly. image

I know Piskel was also having issues with resource creation, unclear if this is similar or not.

I was able to reproduce this same behavior.

Other details

4ian commented 1 year ago

It just includes a relative path to the atlas file in the map json (https://ldtk.io/json/ > Tileset definition > relpath)

Correct, that's the issue here. When you add a ldtk file, the editor read the relative file and add it as a resource. When your project is a cloud project, this notion does not work:

This is indeed a problem for now which means cloud projects won't work with ldtk, unless you edited them locally and then saved as a cloud project.

Silver-Streak commented 1 year ago
  • at all on the web-app, because it has no access to the local file system. We might need to manually ask you "Ok thanks now can you point me to the atlas file?"

Definitely think that is the cleanest solution, something like a popup of "You are adding an LDTK Map to a cloud project. Please select your Atlas image file" .

I wonder if there's a way to reuse the existing Tiled Map Atlas parameter field to make it less special use case.

DignifiedRain commented 1 year ago
  • at all on the web-app, because it has no access to the local file system. We might need to manually ask you "Ok thanks now can you point me to the atlas file?"

Would it not be possible and most logical to Utilize the upload section that is already there? As in, connecting the Atlas map upload for TILED to both TILED & LDTK since they are both read from the same Atlas .PNG?

From a UX perspective, it would seem to me that the most logical thing to do would be to change some text, margin and padding on the Desktop client and require all user-cases to upload the atlas as they already do for Tiled as a general prerequisite?

Since the non-cloud project of GD already notifies the user if a file/component isn't in the project root and asks to clone the requested source, this would create also redundancy which isn't really a bad thing.

Silver-Streak commented 1 year ago

From a UX perspective, it would seem to me that the most logical thing to do would be to change some text, margin and padding on the Desktop client and require all user-cases to upload the atlas as they already do for Tiled as a general prerequisite?

I wonder if the issue here is that the desktop client already does the most effective thing when using a LDTK tilemap, it automatically grabs and adds the atlas to your project resources.

It is more that Tiled maps and cloud usage which doesn't adhere to the best use case.

In my mind, the best scenario would be to require users of Tiled tilemaps to keep the "Embed tileset in tilemap" option enabled for their maps, which includes the relative path to the atlas like LDTK does, and then have them pull in the resources at that point automatically like LDTK does. Leave the "Atlas file" section there, but just if someone wants to replace their tiles with a 1:1 mirror layout that has another tileset (rare, but real usecase).

This is just where my mind goes from "most similar usecase while reducing the amount of manual work for the user."

The Cloud upload not pulling in those resources seems more like an short-term issue, and I think the atlas file field could be a good workaround

DignifiedRain commented 1 year ago

The Cloud upload not pulling in those resources seems more like an short-term issue, and I think the atlas file field could be a good workaround

Agreed.