There’s a huge amount variety between the alternative sbc providers, but I’m general:

• some are simply designed not to have various bits of hardware like the camera 22 pin connector.
• some fail to conform to the pis pin out or footprint, so hats won’t be compatible
• more commonly, documentation and support is so poor that extensive dev/Linux experience is required to get existing hardware to work

All of this makes it difficult to utilize alternatives without conducting considerable research into many different ones.

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