Hey guys,
Is there a way to change the name of instances generated by a factory?
Currently, all items (regardless of the factory) are named instance12, instance13… etc
It would be so much more convenient (for debug purpose) to be able to choose the name in the factory parameters (so i can name them ennemy1, ennemy2, ally1, ally2 etc…)
Thanks in advance!
K
+1. I need it too. Not only for debug but for scripting too.
You can’t do this out of the box, but I can think of a couple of ways to help you with this:
factor.create with your own custom function that maps the created instance id to the url passed into factory.create(). But then maybe you also need to remove mapped instances when they are deleted. Perhaps by monkey-patching go.delete() and go.delete_all(). Hmm, this idea is probably a bit too crazy and monkey-patching is a bit dangerous since it’s not always obvious that a function is monkey-patched and brings potential side-effects.go.get() to identify what kind of instance it is.Maybe additional param in factory.create to specify new object id name?
I found a ticket in our backlog suggestion just that. DEF-1795
Any update on this? Would be nice.
No, no update I’m afraid. This is a “nice-to-have” feature which means that it will be given a lower priority until some of the more pressing issues are solved, namely improved 3D support, extensions and some other improvements for desktop builds.
Yea, It would be greate to have additional parameter in properties of factory.create method for adding custom instance name.
Unfortunately in my case it’s not about debug, it’s about functionality.
Hmm, could you please explain your use case and I’ll add it to the ticket?
After every move I save my game state to the table.
Then, when I want to undo one move, I compare current and previous state and make changes.
Sometimes I delete objects, and when I made undo I should to recreate it.
After recreate I should to replace old object_id with new object_id in the all saved states.
And now I can recieve next situation :
As result I have no one object (it was “instance1” object), because it was replaced with “instance143”.
Yes, I know that my current architecture is not a perfect 
, but now in case when unique instance name can fix all I should rewrited many systems for making workarounds.
About workarounds, what you can offer:
A. Using script with property “uniq_id” - bad idea, I have something about 40 unique objects, and will be more. Adding new script to every GO with one field - is really dirty hack. And I will have many go.get/go.set for checking and compare states - it will not to be a clear code.
B. Do not delete objects, just make it invisible - too many regression for my current code, and we have DEF-2220 - bug when performance too bad on windows with disabled spine animation.
For now I try to change my system with hack between p.1 and p.2 where I will replace instance names with temp_name_n in my table and then replace it with real instance names, when object will be created.
+1
Psssss… we are in 2020 and this problem still not fixed! almost 4 years now
I’m really sorry, this is not a feature. it’s an obvious and trivial thing to have… How difficult is it to change the “instance” naming with the factory name or whatever id you have there?!!
Well, we haven’t prioritized it since we simply had more pressing issues to tackle.
We try to balance the backlog with bigger tasks and “nice-to-have” feature requests, and we constantly feel the pulse of the issues our users face during development. If there are workarounds, an issue is more likely to get lower priority. And we always try to weigh the cost of implementing it with the overall benefit. (e.g. how many users need it to ship their game).
This issue, for instance, hasn’t been requested for the last two years, and as such is quite far down the list (because users constantly request new features)
We will in the future try to look into other ways of showing our backlog, so that users can (hopefully) vote on their most pressing issues, in order to make the prioritzations clearer for all users.
Our internal backlog for the engine and editor (ie not the same as this: https://github.com/defold/editor2-issues/issues) contains 844 open and 365 closed issues. There will always be more open issues than we have time to fix, and we will prioritze issues that are blockers or often requested by our users. This issue is not in any of those categories.
Yes it is. It is a feature request. Not a bug.
Contrary to popular belief nothing in game engine development is trivial. A lot of care has to go into every line of code added. Are there side effects? Will it have a performance impact? Will it break things in existing projects?
One problem is that two game objects can’t have the same id. If we use the factory component id to build the sequential ids of spawned game objects we may run into situations where two factories with the same component id will generate game objects with the same id.
It’s more complicated than I thought it would be… thanks a lot for the detailed explanation.
I realize that @AGulev 's example is from 2 years ago, but could you not create a simple lua module lookup table to handle this?
Local object = factory.create(blah blah blah)
Module.table[“custom name”] = object
Then always reference the object through the custom name in the table in the module. Nil it if it’s deleted (and, you know, create a nil-checker function to avoid nil references later on…), and repeat above step to recreate it if necessary with a new instance ID that is irrelevant?
Yes, you are right. It was almost 3 years ago.
Now when I have a lot more experience with Defold I think that renaming of the objects isn’t important at all.