So I already found an answer to the first half of the question: if I set the value of an exported variable in the inspector, comment the variable in the code, compile, and uncomment it again, the value is gone.

I have a couple mostly identical nodes that I want to store different values in, e.g. I could have 3 "Fruit" nodes and I'd wanna assign "apple", "pear", and "orange" to each, without having to create 3 scripts just for that one variable, how would I do that? Clearly not with exported vars if they can just reset like that. Would metadata be okay for this?

  • xyz and Toxe replied to this.

  • housatic Exported property values are stored in tscn files. If C# build process is not touching those then they should be safe. So backup your tscn if you're afraid a build bug could somehow overwrite them. But in general such things should not happen.

      xyz That would be if I was adding the nodes to the scene with code, right? I have all the nodes in the inspector, and I'm trying to give them "IDs" (not really IDs, they don't have to be unique or even filled) so that I can tell which one is which in code, ideally in a way that I can always see in the inspector

          housatic Clearly not with exported vars if they can just reset like that.

          How often would that happen? Do you plan to add and remove nodes to your scene all the time?

              housatic Just use an exported enum then and don't ever comment it out if you've already placed some nodes. Commenting it out is same as deleting it. You can't realistically expect that the engine will remember values of a property you've deleted.

                Toxe I thought of that but it sounds like it would become a hassle soon. The fruit thing was probably a bad example, I'm going to have tons of these and I could need to change the strings any time. Like one use I can think of, all the nodes have the same properties but different data, I would want to connect a different .json to each one to load the data from (either by connecting the file directly or by giving it the filename)

                • xyz replied to this.

                    housatic Use custom resources.
                    And yeah, storing stuff in metadata is "safer" if you have a property commenter on the loose in your vicinity. Metadata entries are stored in a built in property that cannot be deleted. The drawback is that you manually need to add the entry for each instance.

                        Toxe How often would that happen?

                        It sounds like it can happen if the project just fails to compile

                        • xyz replied to this.

                            xyz Sorry, should have been clearer from the start.
                            My testing project aside, the main thing I plan on doing is passing arguments to functions. One use: I'll have a JSON of objects with "id" and "text", I'll have a function on the node that finds a specific text from the JSON by its ID and prints it when you click on it. I want to be able to easily add or change the ID in the inspector. So I would add "apple" to the node, click on it, it would find "{"id":"apple", "text":"this is an apple"}", and print the text.
                            I can do this with exported variables or metadata just fine, but I wasn't sure how reliable that is.

                            Another, though this should be it's own separate question, I was looking if I could use exported vars or metadata to "overwrite" the texture of a child - basically this question: https://gamedev.stackexchange.com/questions/157845/how-to-expose-a-child-node-s-texture-from-the-parent-in-godot - but also have it update in the inspector and not just at runtime. Maybe using @tool, but I don't know if that's right...

                            The third use is if I just wanna attach some resource to a node, which I've been using metadata for.

                            I just did another test and exported vars also disappear if I delete the mono folder, which is understandable, but I've had to do that in projects before when troubleshooting. Just today, I'm not sure what happened but instead of giving me an error Godot kept using the last successful build and acting like everything's fine, I had to delete the mono folder to force it to rebuild and actually get an useful error message. So if I use exported vars and that problem happens again, all my values are gonna get lost.

                            • xyz replied to this.

                                xyz The drawback is that you manually need to add the entry for each instance.

                                Ahh right, I didn't notice that it was changing the property of the whole object and not just the instance... Well that puts a hole in my little demo.
                                Exported vars would be great for this but today's problem from the last paragraph made paranoid, I highly doubt this is the last time I'll break something in my project like that. I guess I could do a backup beforehand if it happens again.

                                  housatic Exported property values are stored in tscn files. If C# build process is not touching those then they should be safe. So backup your tscn if you're afraid a build bug could somehow overwrite them. But in general such things should not happen.

                                      xyz Huh, I didn't notice, when I build -> delete mono -> restart Godot, the vars disappear from the inspector, but when I rebuild they appear again with their values. So it looks like deleting mono "hides" the fields, but you're right it doesn't touch the values. Alright, I'm just gonna trust it.

                                      • xyz replied to this.

                                          housatic Peek into a tscn file. It may relieve your paranoia 😃