And there’s also WARs for servelets, uberjars, various means of bundling for exes, native compilation via Graal. Overall quite the ignorant meme.
And there’s also WARs for servelets, uberjars, various means of bundling for exes, native compilation via Graal. Overall quite the ignorant meme.
Yep! That would be an example of serialization. In computer science, taking an applications representation of a data type/object and formatting it as a series of bytes for storage or transmission over a network is referred to as serialization, with deserialization being the opposite process.
In your case, I would definitely try out the ResourceUID class as it seems like it may fit your needs. You can use it to create and id and store that with the other fields in your custom data type. It returns an int
so it will be very easy to use as a key in a dict. Just be sure to call add_id after creating so ResourceUID won’t generate duplicates: https://docs.godotengine.org/en/stable/classes/class_resourceuid.html#class-resourceuid-method-add-id
Is there a reason you don’t want to serialize that data with the nodes that use them? Are those values intended to change when the entity isn’t loaded into a scene (like a background simulation or something)?
Seems like adding your own uuid or tapping into the ResourceUid class might be your best option
What is your use case? That would help narrow down a good solution. Node path could likely work. You could also add a uuid or similar (there’s an extension that provides a uuid implementation). Might be hacky, but you could tap into this and see if it suits your needs https://docs.godotengine.org/en/stable/classes/class_resourceuid.html
Doesn’t Israel have required military service?