+1 vote

From the documentation https://docs.godotengine.org/en/3.1/getting_started/scripting/gdscript/static_typing.html. Complete bottom: "Two scripts can’t depend on each other in a cyclic fashion". Isn't that a fatal flaw? Or is there anything I'm missing?

It seems such a huge limitation as to make the static feature typing almost unusable as in practice, it really does not seem to be viable to attempt to consistently try to bypass this limitation. No? I mean, never saw this limitation in an object oriented programming language... Is there really a point to this limitation? Is this just a technical limitation of the engine and is that feature even really usable?

I'm trying to illustrate the issue with an example, and it makes my head spin just thinking about it... Ex: A character has Actions (move, dodge, attack, etc.), and has Weapons. So... If a character attacks another, your action can reference Weapon, but, you can't reference Character from Weapon or Action, so if your weapon cuts off the arm of a Character, or moves the Character's arm as it's swinging the weapon, then... Can't be done because Weapon or Action Scripts can't know of the class Character...

So just because the script Character has some references to Action or Weapon, neither Weapon or Action can ever make reference of Character. I mean that's just so... Annoying and limitative! Is there really a point to try to work with that? Is there a 'best practice' I'm missing?

asked Dec 26, 2019 in Engine by nwgdusr999 (117 points)

I hope someone more knowledgeable than me comes with an explanation why, or maybe a Github issue might be the way to get an answer.
And your specific example, you could make your Weapon never make any actions on the Character and not even know it exists, let all interactions happen from the player side and let the Weapon trigger signals or whatever processing is needed. Maybe the Weapon causes damage to whoever it is colliding with no matter if it is a character or not. Or maybe whenever the Weapon collides with something it signals the player that it collided and with what and let the Character handle it.

Yeah! There are certainly workarounds, but I just don't see them as beneficial; it forces you to put some code where you would rather not put it, and it just seem to complicate things a lot. :/

The character and weapon seem like an odd example. In that case the weapon instance would have to know the exact character instance it's interacting with anyway.
Accessing properties of the character instance is only limited in the sense that you can't test against the type (class) of the character with typeof().

In a real world scenario you would probably instance a weapon scene or a node to your character and then tell the weapon who is holding it e.g.

class Character
  weapon = preload("plasma_gun.tscn").instance
  weapon.set_user(self)

class PlasmaGun
  func set_user(_node):
    gun_user = _node

Right, but given your example, your weapon function set_user(self) could not be typed; Ex: func set_user(character:Character): as that would result in the cyclic error. Which again brings us back to; it's not really usable as such!

Of course, you could simply not use the static typing in that case, but then again, you're not using static typing........ And like the doc said; stick to one style, either use it, or don't.

I've also noticed that very annoyingly, Godot seem to freak out after a cyclic error: Once you get a cyclic error, even if you fix it, Godot will throw random cyclic errors everywhere. Ex: I just made the test function I mentioned to be 100% certain I was correct, and indeed I was. But after removing the function, the Character script started to give nonsensical cyclic errors for other scripts, which were cycically fine. Sometimes just retyping the line in error fixes the issue, but most often you have to restart the editor to fix the issue. :\ That really does not help when you encounter the error the first time!

Please log in or register to answer this question.

Welcome to Godot Engine Q&A, where you can ask questions and receive answers from other members of the community.

Please make sure to read How to use this Q&A? before posting your first questions.