Does Godot have an equivalent to UE4's DataTables? That is, if I have a basic node (e.g. "Consumable"), can I make a struct that holds relevant information (e.g. "Icon", "Name", and "Cost"), then make a list of those structs and reference them by a name/ID/index?

Alternative question:If you were making a list of crafting recipes in the form of "a + b = [c,d,e]", how would you store the list of recipes, and how would you store the list of ingredients?

@Fenreliania i can make a stab in the right direction. If you have a GDScript node expose some properties, they will appear in the scene tree. And then you can make a few instances of the same node, organize them in a hierarchy, and query the tree to create and use your data assets.

@Triplefox Okay so hang on, are you saying that the way you store data in Godot is with just like, a list of nodes, and you search through them by iterating over the children?I think I'd rather be using like, a Dictionary of some kind so I can make "x + y" a key, and look up the result really quickly.

@Triplefox I guess I'm just kinda disoriented right now. I need a list of "elements" and a list of "combinations" but I'm not sure I understand how Godot deals with classes and I'm not sure where to put those lists?Like in UE4 I would make an "Element" Struct, then make a DataTable out of it. In Unity, I guess I'd put an array of that struct in a ScriptableObject? I'm not sure where to put that information in Godot. And I'm not sure how to expose a struct in the editor either.

@Triplefox So I just have like... a node dedicated to holding the list of elements, and a node for holding the list of combinations? Do you remember anything about getting stuff displayed in the inspector? Because trying to get a reference to a Camera2D was driving me up the wall last night and I never figured out how.

@Fenreliania offhand i know that you can do a lot of things by either getting or building a NodePath. That's the data type that lets you start working with the scene tree as if it were a directory structure. Godot really encourages considering the scene in terms of paths vs getting direct references.

@Triplefox That seems... really inflexible. Like I have to count on how I've laid out my scene rather than just assigning references that update if I rearrange things or have multiple things in different places?

@Fenreliania the scene is just a flexible data structure. it is not special. you compose a Godot game out of little scenes and rearrange the scenes internally if needed. If you want an immutable index, make a scene that bodges together a bunch of other scenes.

@Fenreliania it's a really flexible system, so basically it's up to you to decide when you want to stop adding indirection. the whole point of building things to be friendly to NodePath is basically that it means you can describe things by their path address, munge a string to change parts of the path, and be able to swap out assets that way(e.g. "player/armor/head", "enemy/armor/torso") instead of having custom data structures to do all of that.

@Triplefox Do you have any links to resources (particularly videos) that kinda... explain this concept and show how to use it? I'm kinda getting it, but still having trouble figuring out how to structure a recipe, or cast a variable to a type/call a function from another node, stuff like that.

@Fenreliania you might find this GameFromScratch video useful, it starts from the very basics but as he says early on: "there's a chicken and egg problem" since nodes and scenes and how you program with them all get tied together. but he's pretty comprehensive about the possibilities https://www.youtube.com/watch?v=WUARiOGSGKY

they are a *special* container in that the engine knows how to serialize them and present them to UI and will walk through the scene tree to make decisions about updates where the node type is one that touches engine internals(e.g. rendering, physics).

but you can build and address scenes composed in more arbitrary and abstract ways. Hence: Godot's IDE is built within Godot's scene system.