Hey all, I'm doing a system where buildings are being built in stages, and I want to store which objects are visible or not in an array. That way I can quickly set the stage to a number. Conceptually it's pretty easy, just turn on the nodes on a specific array entry.

The problem is, I can't figure out how to get multiple 3D objects on a single array entry. So like array slot 0 just has the foundation. Array slot 1 has the walls. But array slot 2 has the entire house model and 2 cars. How would I make this happen?

I can do the @export var stages: Array[Node] = [] easily, but that only leaves me with 1 object per node. How can I put multiple objects inna single entry?

Oh, and all the objects are on the map, I'm just turning them off and on. I am not pulling in objects to instantiate. Not sure if that makes a difference or not.

  • xyz replied to this.

    if you want to sound cool, some(me) call those "multi-dimensional" arrays.
    "4th dimensional array"
    "array inside an array inside an array inside an array"
    sounds awesome and saves syllables too

      xyz So I am not sure if I am getting the syntax right. I tried doing this:
      @export var stages: Array[Array[Node]] = []
      But I am getting the error:
      "Nested type collections not supported"

      I'm not finding the proper syntax for doing this, is there a change that I need to make in my syntax or do I need to go about this in a completely different way?

          DaveTheCoder Ah dang. Well thanks for the link!

          I guess I will just create a few arrays and fill them with the objects I need. Its not very efficient, but it works!

            CorvaNocta Just declare a plain non-typed array and do all the nesting in the inspector. Or do the whole thing in code without exporting anything. Whichever way is easier for your specific setup.

              packrat "4th dimensional array"

              GDScript/Python non-typed arrays are in fact not classic arrays. They are generalized lists, similar to LISP lists. Those are far more versatile than arrays. Even if you declare the first dimension as having a type, there's no mechanism to ensure that further "dimensions" will be of the same type, or even that they'll be "dimensions". So the concept of multi dimensional array applies here very loosely as such an array is only a narrow special case of the nested lists structure. If you think about it, it'd be legitimate to the same degree to call the GDScript Array - a tree, because it can be utilized to represent trees as well, among myriad other common structures.

                  xyz that's true. they should be renamed to trees immediately starting now. a ton of bugs this past year i blame solely on these arrays being weird as hell compared to the ones i learned with. i never forget the day i figured out why the duplicate method exists.
                  now that i think about it, calling them trees might make other parts of the project pretty confusing..

                  devlog time

                  i had to get very, very creative the past month with keeping arrays typed. especially with this big giant event system that's accessed by dialog boxes, player's actions, events, a dedicated debug console, other stuff, all able to make anything happen equally using properly formatted integers.
                  my solution was when given an index for an in command_idsPackedInt32Array, in order to correctly index a corresponding command_parametersPackedInt32Array(both of which are very often inside an Array[PackedInt32Array]), there's a function that iterates through the command_ids array up to the given index, counting the parameters that should belong to each command_id, and eventually return the starting index for command_parameters where a hypothetical new dimension would have started (assuming the array never gets corrupted as it gets passed around).

                      packrat Lists are quite flexible and easy to work with, can be used in many ways. That's why GDScript only has this one container structure (plus dictionary). Their main disadvantage imho is performance cost. Modern CPU caches love tightly packed uniform data, which is exactly what classic arrays are. If they performed equally, I'd always choose lists over arrays.