#Are exposed properties not treated as part of a script?

1 messages · Page 1 of 1 (latest)

harsh orbit
#

I have an array which I have exposed to godot via GDE. It has a getter and setter setup and working. I can modify the values in the editor save and exit.
I've setup a script to test appending and setting values to the exposed array. It works, when I follow through the C++ code it does append and set variables. However it doesn't update the memory on GDE's side. It does the work and then??? Since the memory location ends up being different from what I had in GDE what is left in GDE is a pointer to the old data. Unless I assign it to a temp holder variable in the script.
Is this expected? It works just fine with basic types (int, float) since the memory location is static and Godot simply calls set immediately when doing +=.

image.png
willow kernel
#

Yes, this is expected and behaves the same way for native engine classes. Create a function if you need to do partial updates. e.g. append_my_packed64(value), technically there's a performance benefit doing it this way so it's not all bad.

harsh orbit
#

Thanks again yesfish. This is what i was afraid of when first looking at arrays.

#

Is the suggestion to have a general set of array functions that you can expose to godot? I guess if i do that i could benefit from Odin's array related procedures but... have to rewrite everything.
Is there a way to lock a property from the gde side? I'm thinking thread safety issues if not using Godot's built in.

harsh orbit
#

Wait a minute. If this is normal behavior why allow this in gdscript? If it isn't a script local variable the data gets created and then disappears.

willow kernel
#

Godot arrays use copy-on-write. My understanding is that every instance points to the same data until the array is changed (resized?), then it's converted to a local copy.

The point being easy thread safety - I think? It's one of those core features that I don't quite understand.
https://docs.godotengine.org/en/stable/contributing/development/core_and_modules/core_types.html#allocating-memory

This sort of behaviour isn't unheard of in other languages, the getter returning a copy of the internal state and users not understanding why it's not updating. Maybe it needs better documentation...

#

If you want to find out more you could join the contributers chat and join the core channel (chat.godotengine.org). Questions should be kept concise and engine related though.

harsh orbit
#

so yeah, that's how I saw it when I finally found the cowdata files.. Coming from other languages it feels weird to force a copy of the data without knowing the intention of the user. Especially when arrays are intended to hold large amounts of data.
But it's fine. I can work around it through the extension. I at least know that it's one less potential problem from the scripts that I don't need to handle. Simplify it to "if there's a set, deref all the old data" Nothing would be writing to the array apart from myself because nothing (barring other overreaching plugins) would be allowed to write to it through the change functions.

harsh orbit
#

Not certain about thread safety. There's several other layers of thread safe read/write handling involved with arrays.
CoW feels more like a half-way immutable state with no option to override the behaviour. Not being able to write to it, but being able to completely replace it is a different kind of choice.

willow kernel
#

Yeah, it violates all my c++ sensibilities. (Just share a const ref, damnit!) But enough people seem to praise it so there has to be some benefit.