How I can modify Simple data extention for my project

Questions
#1

I’m looking for different solutions how I will setup my project that involves so many objects that will conflict 1024 script limit for sure. If I will not attach script to every game object but still I need a way to set some define data values to game objects that I can access with one manager script to make behave according to pre created data values.

For example, whether this object should draggable, holdable edible and so on.

I came across this extention GitHub - defold/extension-simpledata: Example how to bring custom data to a game object
it really suits for my situation but it has some limit.

In script, we can set different values(highlighted in blue) to game object property of game object instance

Frame 823
Frame 8231264×807 95.5 KB

But this is something not possible with simple data extension, I can’t set different values

Frame 824
Frame 8241264×807 60.1 KB

Also what is possibility of modifying this extension for this case, or can I add other types of data value boolean. As I have looked through simple data extension project and I have never touch c++ and clojure before. So how complex this can be.

1 Like
#2

Hmm, I believe that should be possible. Can you please open a bug report in the simpledata extension repo?

1 Like
#3

Just created issues for this - Abitlty to set different values to simpledata properties · Issue #7 · defold/extension-simpledata · GitHub

and one more idea for defining data names from editor - Need a way to define simple data names and its types form editor · Issue #8 · defold/extension-simpledata · GitHub
Don’t know if this is feasible or not. But having this will really improve this extension to easily used in lots of project.

In the meantime, I’m exploring other solutions other than using this extension. I’m really curious if someone had used this extension in production. What are the pitfalls for not using this?

Other solution I can think of maintaining separate json/spreadsheet/lua table data for every objects in collection.

#4

I think e.g. a Lua table is a perfectly valid approach to this.

I’m really curious if someone had used this extension in production.

I’m not sure. We wrote this as an example on how it could be used, for a client that had large amounts of data.

What are the pitfalls for not using this?

It’s another dependency, and a native extension at that. Something to consider when adding to the dependencies list.
As for the data, it’s text based so you can always write a script to convert it back to Lua later on if you change your mind.

In the future, we have even better ideas on how to make the api’s easier to use, and will let us create much better experience with defining custom data in the engine. But there’s really no ETA on that feature.

2 Likes
#5

Also note that the extension is created as an example. That is, the idea is that each project (i.e. you), create your own fork of the extension and create your project specific changes to your own data format.

3 Likes