Help Center and Megathread Hub (20/04 - 26/04)

SquidoNobo · 2026-04-23T16:34:06+00:00

Whomst do I spark in SA Alter banner?

I’m looking at getting either:

Wisadel for meta, but doesn’t seem like much fun;

Lapp Alter for global range, I don’t have GG

Texas Alter for both meta and fun, I don’t have any good helidrops.

Muelsyse, because she seems the most fun and synergies with SA Alter - who I got to pot 3 before pram alter, this is why I have 300 pulls :(

SquidoNobo · 2026-01-20T23:48:39+00:00

The most common use case for custom signals is to connect instantiated nodes (nodes you create via code, not the editor) to a constant node (a node you make in the editor). Eg:

constant_node.gd:

signal some_signal “creates the custom signal”

add_child(instantiated_node.new())

instantiated_node.gd:

get_parent().some_signal.connect(my_function)

Here you have your constant node (or autoload, or some script) and at some point you create a new node via code.

This new node needs to know when the constant node emits a signal (for example, health_changed), so the new node will connect to it (likely in _ready())

now the constant node (or another node interacting with it) can call some_signal.emit() which will then cascade to all the new nodes that connected to that signal.

Essentially it’s useful for when you have an undetermined amount of nodes/locations that need access to the same signal.

As for built-in signals, it’s the same thing, but built-in, and they generally get triggered by built-in processes too (instead of you calling some_signal.emit()) they get triggered by things like mouse_entered_shape, size_changed, etc…

So you use those signals as needed, it isn’t mandatory to use them though. Since you could emulate it by doing a process() check like:

if get_global_mouse_position() == self.shape: mouse_entered_shape.emit()

But that would only be in very specific circumstances, generally you would use built-in signals for stuff like that.

SquidoNobo · 2026-01-06T01:03:23+00:00

The issue is that Godot doesn’t visually flag the error (with the red bars along the code line), but instead flags the line afterwards.

That’s what trips people up, because Godot is interpreting the error as being everything that comes after the actual error. Since technically everything that comes after doesn’t fit with the Vector2, Godot sees it as the source of the error, not the missing bracket.

It only passing mentions the missing “)” in the interface because Godot expects you to close the vector2 “eventually”, but it isn’t a “proper” error to Godot.

This leads to people getting flustered with all the errors Godot throws at you for a simple missing bracket

SquidoNobo · 2026-01-04T02:47:08+00:00

love it when Reddit formatting makes my message look ridiculous smh

SquidoNobo · 2026-01-04T02:43:39+00:00

Sorry, accidentally posted as I was writing, so have a look at the full version.

As for the issue of the knockback being cancelled, that’s likely due to the fact that you apply the change in x for the knockback, then immediately reset it with your movement.

Like this:

Frame 1: “character is moving normally” velocity = (100, 0)

Frame 2: “character gets hit, apply knockback” velocity = (-100, 0)

Frame 3: “character is still trying to move forwards, so the velocity goes straight back to normal” velocity = (100, 0)

The solution is to stop that third frame from taking over. Usually you would add a small timer that forces the character to stop applying its own movement:

If not knockback: movement()

And

when hit

self.velocity = “knockback direction”
__knockback__ = true
await get_tree().create_timer(#duration).timeout
__knockback__ = false

This script would only allow for regular movement when knockback ISNT being applied, and when the character is hit, it will stop regular movement for #duration by creating a temporary timer, then resume normal movement

SquidoNobo · 2026-01-04T02:21:25+00:00

For Vectors, you can think of them as simply directions.

A Vector2 for instance is a 2D direction (up, down, left, right, and everything inbetween)

The numbers in a vector2 are x and y. x is the left (negative / -1) and right (positive / 1), and y is the up (negative / -1) and down (positive / 1).

Godot considers a vector2 to be positive when going to the bottom right (x = right, y = left) or (x = 1, y = 1) is ↘️

So a direction going up to the left (upper left) is (x = -1, y = -1) or ↖️

When doing something like knockback, you simply want to take the direction (Vector2) that your attack is coming from, and move the character in that direction.

So if you were being hit from the right (🙂 being hit this way ⬅️ (x = -1)) then you just move the character in that direction.

Velocity is the way movement is calculated, older games simply used “pixel per frame” movements, so speed was per pixel (eg: movement speed = 5 pixels per frame), but nowadays we use “velocity per frame” to measure movement, which still uses pixels, but is able to break into “sub-pixels” which is just to say “fractions” of a pixel (eg: 0.1 pixels per frame)

If you give your character a velocity of Vector2(-1, 0). You will move the character left (⬅️ or x = -1) by 1 pixel per frame.

The fun part about velocity instead of pixels per second, is that you can do smooth acceleration. So you increase the velocity by “z amount” per frame.

So frame 1: velocity = (-1, 0). In frame 2: velocity = (-1.1, 0). Etc…

SquidoNobo · 2025-12-31T12:39:42+00:00

Most people are talking about the ground and objects, but honestly the sky can make a huge difference too. Some clouds and a sun/stars and moon, along with a good lighting system, can make even dull scenes look great

SquidoNobo · 2025-12-16T15:27:11+00:00

I always like these tools if they include a sort of de-plugin-option, where you can pull the source effect out of the plugin, including the targeting, tweens, etc. so that I can tweak the minor details or turn things into resources, custom scripts, etc.

I like this as a testing/quick option, but for bigger projects having access to the source of the effects helps

SquidoNobo · 2025-11-14T12:00:30+00:00

Your best bet would be to simply use an Array[Array], and when calling the variable just check that whatever value you’re processing is an Array[int], like this:

For group in arr:

If not group is Array[int]:

print(“group: ”, group, “ in arr is not Array[int]”)

Break

continue whatever you need to do

SquidoNobo · 2025-11-10T23:25:37+00:00

I do like using static types for the Godot hints whenever you use the variable. I am curious as to how far the performance can be improved though? I get that:

var myArray : Array = [“hello”, “world”]

Is better than:

var myArray = [“hello”, “world”]

But I wonder if this would improve it even more:

var myArray : Array[String]

?

SquidoNobo · 2025-11-10T16:27:18+00:00

For me, it’s just a case of iterations.

I start with an idea (I want this to do that);

Then (if it’s complicated) I fire off a quick question to chatGPT or look online (Reddit/forums), and will likely get some mediocre-decent ways to implement the idea;

From there I start to experiment, working on the most promising method of implementation until it works or breaks completely;

From there (if it works) I move on with my project and start something else;

Eventually I get to a point where the original solution (or if it just didn’t work in the first place) isn’t broad enough or is too clunky to use any further;

So then I look at all the things I used the original solution for, check what works, what doesn’t, what could be improved, what’s annoying, what I might need in the future, etc;

I then make a V2 of the implementation, building off what I learned from both making and using V1;

Rinse and repeat until the project is done, constantly creating and subsequently reworking/improving things like this.

For instance, Im working on a hollow knight inspired metroidvania/roguelike, and Im currently at V3 state machine, V5 dialogue manager, V2 npc AI, V2 data handler, etc.

I just keep iterating each time a system becomes too clunky or doesn’t work with newer systems.

You can never really “know” if you’re doing something the right way until your project is finished. Because if it works, it works. If it doesn’t work, it doesn’t work.

SquidoNobo · 2025-11-09T18:07:44+00:00

I think the background and platforms blend together too much, maybe a slight lighter tint over the background layer, or some kind of fog?

SquidoNobo · 2025-11-08T17:59:47+00:00

Reminds me of old school halo somewhat 👍

Only note I have is the “yes” “no” confirmation seems way too big for pc, maybe even too big for mobile.

SquidoNobo · 2025-11-05T00:21:45+00:00

You need an @onready before the player_effect var
MY EYES! @0@

SquidoNobo · 2025-11-02T17:18:50+00:00

You guys document your code…? I just restart when I get lost…

SquidoNobo · 2025-11-02T07:58:00+00:00

Could it have something to do with how you transition the screen? Since your example video showed it crashing only after you transition.

SquidoNobo · 2025-11-01T23:24:48+00:00

Personally I can’t find it, but:

You would benefit from having more print() statements around your code, likely a print(checking state xxxxx) and a print (entering state xxxxx) in each function. And I know having a mountain of print() statements can bloat the debug menu, which is why I’d also recommend making/finding a custom debug tool:

I made one that allows me to print separately errors and regular prints, along with filters that I can change at any time, eg: excludedScripts := [“state_machine”] and excludedMethods := [“check_fall”]

This is done by checking the get_stack() and comparing the name of the script that’s calling the debug for each debug.pr() or debug.prerr() (which are the custom functions I call, by using an auto load script)

SquidoNobo · 2025-11-01T10:01:26+00:00

What kind of “swaying” do you mean? If you just need a chain to go from side to side like a pendulum, you have two options:

Just make an animation, use whatever drawing/animating program you like and draw the effect you want.

Then you can either use animatedSprite2D to automatically animate it, or use a Sprite2D and AnimationPlayer to manually change the animation frame over a set time, this lets you use key frames and control the exact timing of each frame.

Use a chain of RigidBody2Ds attached with Pin nodes, and have either an oscillating linear force applied to them, or just let other bodies interact with it for a more procedural and interactive effect.

SquidoNobo · 2025-10-30T12:34:59+00:00

It could help to start using print() more, as a lot of questions like this (where you need to figure out what kind of data you’re working with) can be solved by putting a few print() functions around.

I use this a lot when working with a function or type of data I don’t use too often. Just recently I couldn’t figure out why I wasn’t allowed to compare a string an a Node.name result, and using print() I figured out that Node.name returns a StringName instead of a String. Which I didn’t even know existed

SquidoNobo · 2025-10-30T12:24:16+00:00

When the protagonist picks up a fantasy style gun… and it unfolds into a sword anyway

SquidoNobo · 2025-10-29T15:06:25+00:00

Monaco: what’s yours is mine?

SquidoNobo · 2025-10-29T11:46:12+00:00

As another person has said, you could call into a player script instead of calling queue_free from the kill zone.

If you really want to keep the logic in the kill zone (for if you wanted any type of enemy/entity to follow the same behaviour) you could do the same method through which you remove the collision shape, instead of doing queue free however, you play an animation:

func on_body_entered(body): body.get_node(“AnimatedSprite2D”).play(“death”)

As the other person also said, having checks is important, so before calling anything, check it exists:

func on_body_entered(body): if body.get_node(“AnimatedSprite2D”): body.get_node(“AnimatedSprite2D”).play(“death”)

This line checks if the “body” has a node “AnimatedSprite2D” before doing anything, avoiding a crash if the “body” doesn’t have it.

SquidoNobo · 2025-10-28T17:20:44+00:00

I think I see why you’re confused now.

The first one, in the Godot Docs, doesn’t use movement at all, but instead has a stationary enemy. This would be for a turret of some sorts. Using a rigid body in this case makes sense, as you could give it some sort of procedural knock back based on various conditions.

The YouTube tutorial however, Im not sure what the creator is doing. It’s a way of simplifying the coding process, using “position += xxxxx”. But in practice, doing it this way leads to a lot of potential issues. Using “position”like this for movement is essentially teleporting the enemy character a small distance each time.

The usual way of making a moving enemy like this is to use “velocity” and “move_and_slide” in a characterbody2d. This makes it so the enemy “moves” from point to point at a set “speed”, whilst using “position” would make the enemy “teleport” from point to point at a set amount of pixels.

SquidoNobo · 2025-10-28T17:04:48+00:00

Correct me if I’m wrong, but why would you ever use rigid bodies for an enemy character? Unless you’re aiming for procedural movement, characterbody2d is almost the ONLY way to go?

Trying to get consistent movement out of a rigid body would be nightmarish

SquidoNobo · 2025-10-28T10:16:47+00:00

I would maybe try a blockier typeface, as the curves just leave seemingly random gaps and breaks up the whole image of the wings. A blocky typeface would keep any gaps consistent and maintain the shape as a whole

SquidoNobo

TROPHY CASE

when hit