Load Tiled from external resource

[andreas-volz]

Is your feature request related to a problem? Please describe. All my TileSet and TileMap resources aren't in the Godot project directory while build time.

Describe the solution you'd like Load the Tiled TileSet and TileMap + Images with the ResourceLoader at runtime from external path. I've read in the README by today it's a problem. But is this possible to change or should I search another solution?

Describe alternatives you've considered Loading my own internal map format instead of Tiled with YATI.

Additional context I write a Starcraft data importer and couldn't deliver the TileMap and TileSet together with my Game. For unit graphics I've yet a working ResourceLoader. It works with YATI, but only when I import them in the Editor.

[Kiamo2]

Unfortunately, I see no way to get there.

YATI is not a stand-alone program, but a Godot import plug-in, its start and running is controlled by Godot and is subject to all Godot specifics. And Godot expects all its required resources within the res:// folder. The required resources include the PNG files and the .tmx/.tmj file(s).

.tsx/.tsj files can be placed outside, but must be correctly referenced in the .tmx/.tmj at runtime so that they can be found. And those .tsx/tsj files must in turn correctly reference PNG files located inside the res:// folder... In the end, this is quite complicated, so I wouldn't go for it.

Instead: It is almost certainly possible to configure the game export in a way that no .tmx/.tmj/.tsx/.tsj files are included in the delivered game.

[andreas-volz]

Thanks for your fast answer. The problem is indeed not the generated Tiled file, but the copyright of the PNG data and in worst case the mapping of tiles in the scene. I load every single PNG in my game by a user provided external Resource at runtime that is converted by an external tool. So my solution must not to be a Godot Import plugin. I'll have a look in YATI code and see if I could use it go reach my goals.

[Kiamo2]

Haven't the PNGs to be somehow present inside Godot to be useable in the game? Don't quite understand how this technically should be working. Or has Godot a built-in means to obfuscate the PNGs inside a deliverable?

[andreas-volz]

I'm only delivering the Game executable, but not the data. This has every user to export with a supplied toolchain from his/her own bought copy of starcraft. I'm using the PNG ResourceLoader mechanism from Godot.

[Kiamo2]

By chance I've got a special request from Pyral on the Tiled discord channel. Would this (what he wants/suggests) be of interest for you?

[andreas-volz]

It seems I've no access to this discord server.

[Kiamo2]

This is, what he requested:

Probably a long shot to suggest this, but would it be possible to, in the runtime scripts, eventually support passing a PackedByteArray or, better yet, a Callable that returns a PackedByteArray, instead of only passing in a filepath string? The reason for this is because it'd make it possible to load tmx/tmj/blah files directly from ZIPReader.read_file as well as allow extending how files are loaded without modifying the plugin itself. In our project, we have a separate Godot project which is a dedicated editor that compiles all assets, including tilemaps, to a single zip database. So tiled files have to be loaded directly from zip (avoiding any terrible hacks like dumping to /tmp or something and loading via FileAccess from there) I've got a proof of concept working which can load TMJ/TSJ. XML could theoretically work too, but XML's loader is more complex and has its FileAccess calls deeper. I was able to directly convert ZIPReader.read_file()'s PackedByteArray dump into JSON and pass that into the JSON loader. It's just a bit of a hack though and I had to hard-stop normal file loading as a result just to get it working with my runtime. I can see where improvements can be made to make the data flow better. The main thing is just decoupling the loading of the PackedByteArray from the actual parsing of the XML/JSON files. I'd probably be willing to share my hacked up version of the runtime importer, if it's not too unwelcome. This is for YATI, I probably should clarify, in case there are like six other Tiled loaders for Godot.

I have to admit that I don't understand everything in detail about what he has in mind, just the general direction.

[Kiamo2]

I am currently taking a closer look at the YATI runtime version (because of the Pyral request). And I was pleased to discover that the restriction that all sources are in the project does not exist here! That was news to me because I hadn't even tried it out yet.

My suggestion is therefore to use the YATI runtime version.

[andreas-volz]

Thanks for that hint. I'll try it out in the next days.

[andreas-volz]

Is there an example how to use the runtime version? I assume the import process has to be invoked from some API calls.

Edit: Found it => https://github.com/Kiamo2/YATI/blob/main/Runtime.md

If I correct understand the code that the texture might also load relative to an external path: https://github.com/Kiamo2/YATI/blob/a319aa55751b45351666e6d0a364cefeca79ef3d/GDScript/runtime/TilesetCreator.gd#L233

[Kiamo2]

Not sure about that - and must admit that I don't remember exactly. The method 'LoadImage' makes some effort to compose the path to a fully qualified one and there's probably a reason for this.

[andreas-volz]

I could confirm loading a .tmj with the runtime loader works perfect!

There're still some problems if I try to use the ResourceSaver to save the tileset to now use the loader next time again. But that's a minor issue. If I'll fix this I add a pull request.