Stuck due to engine design?

Questions
#1

I modified Tiled to generate .collection files, to allow usage of multiple tilesources per tilemap in Defold (here’s the pull request in case anyone needs it, too).

I’m now trying to allow usage of animated tiles.

My plan was to generate a .lua file to go along with a .collection file. In that .lua file, I’d keep information about which tiles need to be animated in what way.

Inside the collection, I have a custom “TileAnimator” component. This component is supposed to do the animating, but it can’t read the associated .lua file, because script properties don’t allow strings, which is what you need to save the path to the file. (which @Ragnar_Svensson said was intentional)

And I don’t see how I can get the path to the correct .lua file through code, either (I spawn them through collectionfactory, and the collection’s path isn’t exposed as property either!), without creating some shared table which I’d have to fill in manually for every collection I intent do use. I want each tilemap (.collection) to be self sufficient once Tiled spits it out.

Is it possible in Defold?

2 Likes
#2

Why do you need to store the path to the file in a script property? If you generate a .collection and a .lua file can’t you then also generate whatever other “glue” code that you need to tie things together? Do you even have to generate a .lua file? Can’t you generate a .script file and put the data in there?

#3

That would work, but I’m a little unsure about how much potential it has for creating overhead. We’re talking about ~160 identical scripts that are basically unnecessary. Only ~10 of them would ever be simultaneously loaded in memory, but still… Is it a good solution?

#4

I don’t think I really understand what it is you’re trying to do here. Can you please explain a bit more about your use case, the files you generate and where and how you plan to use it?

#5

How I solve this kind of problem usually:

some_module.lua

local M = {
[hash("key_value_1")] = "string value"
[hash("key_value_2")] = "string value 2"
...
}
return M

some.script:

local some_module = require "path.to. some_module"

go.property("key_value_1", hash("default string"))
go.property("key_value_2" ,hash("default string"))

function init(self)
  print(some_module[self. key_value_1]) -- print string
end

In your case, when you wanna use path to lua file some_module.lua (ver.2) will be:

local M = {
[hash("key_value_1")] = require "path.to.your.lua"
[hash("key_value_2")] = require "path.to.your.lua2"
...
}
return M

Even if you will have strings in properties, the builder will not include this *.lua files into the build. Because we parse all script files and looking for require "path" to decide what lua modules should be included.

In a case with some_module.lua (ver.2) lua files will be included to the build.

5 Likes