Add sub-nodes via class?

[insomniacUNDERSCORElemon]

I am the first to say that using the editor is easier (and I probably should do that now) but I've been thinking that it would be neat to create nodes in a class (all in code) particularly for simple setups. Additionally, this would allow using exported data for node structure rather than needing multiple instanced scenes (the downside to all-code being that the ready function would need to run in the editor/as a tool script in 3.2, at least to display anything other than a placeholder).

I am particularly thinking doors with this (sci-fi/elevator doors, or the same thing but with multiple cylinders as the visual for a locked/dungeon look). Though mentioning the exported data for different types also makes me think of other interactables like barrels or switches that have often have variants with different implementations.

While some of this is also related to how classes show up now (which encourages re-using classes), more code just for a slightly different workflow obviously makes more sense for a library/plugin or shared code snippets etc. than it does for most projects. Though all-code seems like it's a thing with dungeon crawlers, so would be a good thing to have an example of somewhere

[panno8M]

Does all-in-code mean that we do not use textscene (tscn) or other resource types?

At least for the examples given (like door and cylinder, or button and plate), although it should be using Skeleton3D, but it would be useful as a demonstration that it is feasible.

I cannot present a conceptual implementation for this, but I can show a way to do it simply:

type MyDoor* = ref object of CollisionObject3D

method ready (self: MyDoor) {.gdsync.} =
  var cylinder = instantiate Cylinder
  cylinder.name = "cylinder"
  cylinder.basis  = ...
  self.addChild cylinder

[insomniacUNDERSCORElemon]

Does all-in-code mean that we do not use textscene (tscn) or other resource types?

The first for sure, the second depends on desired aesthetics (and if someone wants all functionality to work as a self-contained file). I personally would go with the second unless I was going with importing vertex-color models (which would probably be later-on in development of a project if I ever get that far).

although it should be using Skeleton3D

I saw door tutorials with animationplayer, tween, lerp, exported values and clamp etc. but not Skeleton3D. I'm sure it'd work but it seems like not so great for non-deformable stuff, the only thing I could think of is if that setup makes it easier to do constraints and maybe physics like the types of games where a door can be blocked or manually moved (maybe even taken off the hinges, rigidbody door I assume). Even then, I'm guessing the different joint types could allow those things as well (with easier control on movement constraints, like hinge vs slider).

With above, (mostly) code-less doors sounds intriguing for opposite reasons (also: areas for forces for closed/open/lock) but testing it and I'm getting some wonky-ness with physics already. I guess maybe I should just go with simpler doors that just get hidden first, add animations in later. EDIT: I should say this was after I tried tinkering with the code above and couldn't figure out anything.

I should also say that another area where code may make more sense is for projectiles, more so than doors due to the context (something that is on-screen for part of a second flying away rapidly from the player usually doesn't call for much visually).