loopier / animatron

Animatron for Godot 4.x <
15 stars 1 forks source link

On routines #26

Closed loopier closed 2 months ago

loopier commented 7 months ago

On our last meeting I think we agreed to implement /routine similar to /def. But, do we really need to do that? Can't we just make /routine call one command and, if we need to do more complicated stuff, call a /def? We mentioned using dedicated variables, like iteration or index or repetition. We could still use those passing them to the /def:

/def /bla a
    /create x$a foo
    /rotate x$a {$a % 360}

/routine bar 20 0.5 /bla $iteration

Another issue with Routines: they are handled in Main but the callable is in CommandInterface. The current solution to this is making the callable emit a signal that is caught in Main. I recall you saying this is not a very good idea, but I can't think of an elegant alternative. Any suggestions?

totalgee commented 7 months ago

Yes, that was always an option, and is fine with me.

totalgee commented 7 months ago

Another issue with Routines: they are handled in Main but the callable is in CommandInterface. The current solution to this is making the callable emit a signal that is caught in Main. I recall you saying this is not a very good idea, but I can't think of an elegant alternative. Any suggestions?

Sorry, I haven't really thought about it much so far. I it's not so great to call get_parent() in the _ready() of a class (or get_parent().get_parent(), which is what they call a "code smell"...). But there are cases where it's maybe a fine solution -- I'm open-minded ;-) -- like when you know the relationship is a "static" structure, that the parent exists and must be the one creating the child, and both objects are in the same Scene. I've looked at some "dogmatic" threads like this one which are interesting -- but be aware this is one of many opinions; be sure to read the following comments!

I would try to stick to recommendations from the Godot documentation itself, such as some of the ideas here, which gives some good suggestions for cases like the one you describe:

https://docs.godotengine.org/en/stable/tutorials/best_practices/scene_organization.html

loopier commented 7 months ago

I would try to stick to recommendations from the Godot documentation itself, such as some of the ideas here, which gives some good suggestions for cases like the one you describe:

https://docs.godotengine.org/en/stable/tutorials/best_practices/scene_organization.html

I read the article. The first option it gives is emitting singals: "_Connect to a signal. Extremely safe, but should be used only to "respond" to behavior, not start it. By convention, signal names are usually past-tense verbs like "entered", "skill_activated", or "itemcollected".

The other options are variations of the parent (Main) setting a property of the child (CommandInterface) to hold itself (instance of Main).

I was doing the first one. When on command received, Main passes it along to CommandInterface which, in some cases, triggered a signal caught by Main. We could do it for all commands that need Main to do something.

From the other solutions, the less awkward to me would be Main setting the $CommandInterface.target = self property. But still feels "smelly".

What do you think? Have you read the article? I stopped reading when it starts talking about changing scenes, which I think we don't need at the moment.

loopier commented 2 months ago

Closing issue, as I think the solution mentioned above has been working for a while and seems to be a correct one.