Change ID for script attachment from collection caused confusion (SOLVED)

Bugs
#1

The latest update disabled the ability to rename scripts within a collection. This completely breaks my game. View the following screenshot:

image
image.png503×942 16.4 KB

I have set enemy_instance to “go” and I also have non-generic enemies which have their own scripts using “go” as the id value. They share the same properties so this is a way for me to implement a rudimentary form of generics in the lua code. Without this, my game cannot continue developing unless I revert to the latest version and refuse to update.

In light of this change, I’m wondering how hard it would be to implement a more proper inheritance system in the game to combat the loss of this vital feature.

EDIT: The enemies I had previously created still somehow have the id set. If I change the value in the text editor nothing happens though and saving reverts. Why was this change made? It seems to only serve to break existing games not add any new functionality.

#2

Which version did you run before 1.2.175?
This is what it looks like for me in 1.2.174:

28
Screenshot 2020-11-18 at 10.14.28.png856×1096 34.8 KB

Afaik, we haven’t changed anything related to this.
And, to be fair, the id of a node in another file on disc is not something I’d consider as a “property” to be overridden.

1 Like
#3

It was working for 1.2.176 the update that came out just today seemed to change it I think. I’ve kept my version up to date constantly. If there’s no way to override this then there’s no way to implement generic property retrieval for a set of similar objects with differing scripts without reverting to using a global table, etc. The way I’m doing it I much prefer as I can simply overload the init, update, and on_message functions for each sub-script and then set the id of each the same for retrieval by other objects that deal with this type.

EDIT: Looking at my version logs, I made this change to the enemy system on October 24th. So the breaking change occured sometime between then and now. I am trying to add more enemies to the game and now I am unable to proceed due to this.

#4

This is not a released version. We recommend using the editor-alpha version.

seemed to change it I think
October 24th.

Downloading an old editor from here (files named “editor-alpha.editor2.Defold-*”)

Then create a repro for us where we can test this feature with an old editor and the new 1.2.175.

1 Like
#5

Downloading an old editor from here

Are you saying you’re doing that or you want me to create it? I can do so if it will help. This seems like a strength of the engine, being able to use similar ids for different scripts. This just allows the developer to break up the code more easily when necessary. Is there any downside to this? I suppose someone could accidentally use the wrong name for a script, but this seems like the user’s fault not something that should be prevented by the engine.

1 Like
#6

Since I’m still not clearly grasping how to reproduce the issue, I’d like for you to do it, so that I can reproduce it locally too.

In this case, the property is regarding the hierarchical structure in another file, and I have never seen it being possible to override from another collection. So I’m really interested in seeing this bug reproduced so I can take a look at it.

#7

Ah figured it out! Apparently it’s because the object w/ the id override for the script was trying to be set at the collection level instead of the object level. I’ll upload an example showing the structure of what I’m describing so that hopefully support can be retained for this workflow.

#8

I can assure you that we haven’t made such a change. But I’m also not sure exactly what you are trying to do.

If you want to rename the id go of the script component /game_objects/enemies/enemy_instance.script which is used in basic_flyer_enemy.go I believe you need to do so by editing basic_flyer_enemy.go. You cannot change that from the collection which uses basic_flyer_enemy.go.

1 Like
#9

Thanks, yes I realize my mistake now. Since some things can be changed in collection level I was used to modifying them there (such as swapping the model for an object.) There’s a bit of inconsistency here which is slightly confusing to me. Here’s a copy of a simple project (created in 1.2.173) which implements the behavior I’m hoping will be preserved (since it’s of great use to me.)

generics_example.zip (91.2 KB)

1 Like
#10

Which behavior are we talking about now?
We haven’t supported renaming id’s in another game object file, from within a collection file.
And you state so yourself, that it was a mistake?

So, there’s no behavior to be “preserved”?

#11

Hah sorry yes I made a mistake. However it would be convenient to be able to modify the id name for a script attached to an object via the collection editor similarly to changing the model mesh, etc. As is, you have to double click the object then change it there whereas the model is swappable directly from the collection. This led to me believing it had been locked out but I had simply forgotten how I had initially set it up since it’s been awhile since I came back to this area of the code.

1 Like
#12

Ah, ok.

Well, I think renaming the id, is a fairly rare occasion compared to altering the rest of the properties. And it’s also be very confusing for the user, that it would not be an “override”, but actually a change to the original file.

1 Like
#13

True but there could be a revert button similar to other overridden properties simply omitted. This should indicate the original is changed and not overridden then (same as models.) It’s not a big deal though, sorry for freaking out a bit. I’ve been putting way too many hours into the game trying to prepare for Google Play launch so I’m just a bit fatigued :blush:

EDIT: Changed the title to be less alarmist. I looked at the source for the collection and saw that the id was modifiable there and so assumed falsely it had been locked out since it was reverting itself when I updated it. I should have investigated longer :stuck_out_tongue:

#14

I’ve actually been meaning to start a threat about this, but haven’t gotten around to it just yet.

I’m pretty sure when changing properties in the wrong place in the hierarchy, the change shows up in editor but doesn’t actually happen and only restarting the editor “reverts” it.

#15

Uh oh! No need to become hostile :fearful: Start a threaD instead! :slight_smile:

3 Likes