@foxysen ?

@foxysen nope

ah, in a similar vein, ClassDB, the “class information repository” for “every available class”, only stores engine classes. script/user classes are stored in ProjectSettings

and while i’m thinking about types, i’m sure there’s a good reason but why are there so many special cases in the godot typeof keyword??? vector2, vector2i, vector3, vector3i, vector4, and vector4i are all entirely distinct from one another?? like, those things aren’t similar in the slightest??

so now im trying to serialize/deserialize godot structures for my save/load system, and apparently

• Object.get_class() -> String returns the builtin/native class name from which a class derives, not the name of the actual class
• as of Godot 4.3, there is a Script.get_global_name() -> String which returns the class_name of a script!
• … expect if it’s declared as an inner class, which still has no way to get its name

im

Hover to show content

@kasdeya if you use a Map instead of an object, you can also do

const someDict = new Map()
someDict.values().some(value => !isPrimitive(value))

@Ry oh thank you! 💜 i haven’t been sure when to use class_name since i was running into issues with it and autoloads (apparently having an autoload with a class_name causes a name conflict??)

@kasdeya this isnt gonna make it thaaaat much better but you could do

Object.values(someObject).some(value => !isPrimitive(value))

(especially since i think the python version of values is a lazy iterator that stops on first match and the javascript one isn’t)

also a minor gripe, type hinting is Really Fuckin’ Annoying when i have to import all my other scripts in order to hint with them. why ??

const Player = preload("res://src/player.gd") # okay but what the fuck is this

func damage_player(player: Player):
  player.apply_damage(5)

as far as i can tell, the one node, one script thing encourages some kinda shitty habits that i didn’t have a problem with in Unity or any ECS architecture. for example, code reuse comes from one of three things: a child node, a global/autoload, or inheritance. splitting every shared functionality into a shared node feels like overkill sometimes, especially when it comes to trying to make those nodes communicate. i don’t want to have to connect a bunch of signals for what could have been a simple function call

globals/autoloads are Okay but not always the most ergonomic. (i’m also lumping a class with static methods into this approach). like, it just feels kinda dirty to do it this way.

# node_ext.gd
class_name NodeExt extends Object

static func find_child_type(node: Node, variant: Variant) -> Node:
  # blah blah find node


# other_node.gd
func some_fn():
  var found_node = NodeExt.find_child_type(a_node, CustomVariant)

like yeah this gets it done but i just kinda hate doing it this way. c# at least has extension methods

// nodeext.cs
public static class NodeExt {
  public static Node FindChildType<T>(this Node node) {
    // blah blah find node
  }
}

// othernode.cs
public void SomeFn() {
  var foundNode = aNode.FindChildType<CustomVariant>();
}

and inheritance just kinda sucks, so i feel like i’m only left with one option for code reuse in godot lmao

so in godot’s fairness, i really love how quickly the game launches compared to unity. no compilation time, no waiting on domain reloads. it just opens. love that

i’m still having a hard time adjusting to the one script, one node design but i think i can eventually get used to that. i can’t say i enjoy the cognitive load (or performance burden) of a deeply nested scene graph though.