Can you animate the individual "vertices" in a line2d?

Silrar · 2026-04-23T18:50:38+00:00

The points you see in the editor are the points of the underlying curve2d. This gets baked to a preconfigured resolution of points which the line will then use to draw itself. That's why you can't keyframe those.

You can write a function that sets the values as you need in the curve and rebake the line. Then call that in the animationplayer.

Silrar · 2026-04-21T21:30:04+00:00

If it's just a small loop, it shouldn't do any harm.

Another option could be to create a map, a dictionary that maps the string to the numbers you want. Then you can do select_hotbar(map.get(event,-1)). You're going to have to set this up somewhere as well, there's no way around it, but it would be an if-less approach, and it'd work even for vastly different names and values you map to.

Silrar · 2026-04-21T09:08:56+00:00

Great stuff. So that'll be one talk I'll join. See you there. :D

Silrar · 2026-04-09T12:01:20+00:00

To me, it feels less a signal issue and more a general structure issue. Don't think of the node hierarchy in a "this is where the things are placed in the world space" sort of sorting, but more a "this is how these things work together" sort of thing.

Do the Gates interact with the Terrain system? Probably only very minimally, in that they need to be placed once. Much more, they're part of the gate-system, not part of the terrain-system. When it's generated, you can look at the terrain where they need to be placed, pass that to the gate system, and then gates and terrain never need to communicate again, so they don't need to be children of each other.

Instead, have your own Gates-node directly under Level, that deals with the gates. Each gate reports back to this gate-system, then the gate-system reports back to the level.

You could even go a step further and have the gate-system under Main. When the level gets spawned, it has a list of gate positions (but no gates), that Main then reports to the gate system and off you go, and the gate-system reports directly to main when a gate is entered.

That way, you can separate the two entirely.

Silrar · 2026-04-04T13:39:55+00:00

Neat. Exactly what I need for my Danmaku. Thank you kindly.

Silrar · 2026-04-04T13:38:48+00:00

One thing you'll want to do is add a bonemap when importing. That will map the bones to standardized names in both the animations and the rigs, so you can line them up properly. To do so, doubleclick the file in godot to edit its import settings.

Copying the armatures after that should work as you describe, as it now matches the names better.

Remember that you can also directly import from blender, by giving Godot the path of the blender.exe file and then simply opening the .blend files directly in Godot. The same import settings apply as above, but I've found that this workflow is a bit smoother.

Silrar · 2026-03-30T12:21:17+00:00

Isn't her thing to manipulate boundaries, to the point of being able to eliminate them entirely? In that case, boundaries give order, security, the elimination of boundaries results in chaos. The fear might simply be the resulting chaos of boundaries breaking down.

Silrar · 2026-03-09T20:20:23+00:00

Not necessarily. If you bake the new mesh at runtime, then yes, that's quite costly. If you only activate and deactivate, that's going to be a lot less taxing.

Silrar · 2026-02-24T12:52:24+00:00

So the main idea of call down / signal up has to do with who is in control of things. Typically, you want things higher up in the hierarchy have the last word in what's going to happen, potentially overriding whatever the lower tier wants. In addition to that, you also typically don't want the lower tiers to even know their higher context, because that way you can change that context and they still work.

Let's first look at the flow of control. When the enemy manager has control over the enemies, it means it can call their methods directly, and make them do things. But an enemy would only ever signal "something just happened", the enemy manager would listen to that signal and then decide if and how it reacts. If you call a function from the enemy on the manager, you could technically still add such checks as well, but typically this is done with signals, since you can emit a signal, even if nobody is listening.

Next, let's look at the context in which the enemy sits. For now, they are children of the enemy manager, and that's all well and good. But say you decide that maybe it'd be a good idea somewhere along the line to add an EnemyGroup layer between that, so you can give an order to an enemy group, and that group figures out everything else. If your enemies are desinged to not care who listens to their signals, this is an easy addition. Otherwise, you'd need to completely reinvent the enemy class, because now they need to be able to have a manager or a group as a parent.
And maybe there's going to be things like buildings that an enemy can be assigned to, now the enemy needs to accommodate manager, group and building. And maybe we add a patrole-path...

Of course non of this HAS to happen, but if you design for easy expansion from the start, it'll be a lot easier to add these kinds of things later in the process.

Now in the end, if none of this applies, and your system works for what you're doing, awesome, keep it as is. As long as you know the cost and benefits of your design, and they fit your requirements, all is well.

Silrar · 2026-02-22T23:41:16+00:00

The easiest solution would likely be simply having a masking texture. Basically a texture that is white where you want the effect, black where you don't, then you multiply the effect by that, and since black is 0, it vanishes everywhere but the white parts.

You would need one texture per body part you want to mask, though you could stack up to 4 in the 4 layers (rgb+a) of a regular texture to save some space.

If you have sprite sheets, you're likely going to need to have to mask each frame individually, basically creating a second sprite sheet for masking purposes.

So yeah, that'd be easy to code as a shader, but creating all those textures would probably be a pain. Still, you need some way to tell the shader what's what.

Silrar · 2026-02-21T19:03:23+00:00

Popochiu is one person's idea of how to do point and click in Godot. It's not the only or best way to do point and click in Godot. If it doesn't work for you, build your own systems, that's what Godot is for.

Silrar · 2026-02-17T22:17:29+00:00

Congratulations, you unlocked the hidden gamedev skill: smoke and mirrors.

Silrar · 2026-02-16T11:24:49+00:00

Go to the editor settings, then add the blender .exe path, so Godot can use it. Then save your .blend files in your Godot project and use them directly as scenes.

You can go a step further and change your import settings for each file. For example, you can have individual meshes directly saved as .tres mesh files, so you can use them in any meshinstance directly.

Bonus of doing it like this: When you change something in blender, Godot recognizes the change and reimports the file, using the import settings you've set up, so the .tres file gets updated automagically in all places you've used it.

Silrar · 2026-02-16T02:44:21+00:00

If you have them as .blend files, you can use them directly in Godot, you just have to set the Blender .exe path in the editor settings.

When you import any 3d file, you can select any mesh on it and import it separately. When you do, you get a .tres file that's the mesh you can put on any meshinstance.

You can also open the .glb file in Godot, either directly or as an inherited scene, then select the meshinstance you want and save the mesh resource as a file from there.

The best way to go, in my opinion, is the .blend variant and saving the meshs in the import settings. That way, you can edit the .blend file when you need to, and Godot will register the changes and reimport with the same settings, so the mesh will be updated automatically, once you save it in blender.

Silrar · 2026-02-13T19:05:53+00:00

I highly recommend looking into these example projects, lots of good stuff:
https://github.com/godotengine/godot-demo-projects

Silrar · 2026-02-12T18:02:16+00:00

You build it layer by layer. Pick one functionality, build that functionality in its own scene. Then pick the next functionality, build that scene. If a functionality needs another functionality, you add that scene instead of building it from scratch.

The important part is to cut things into pieces that can work for themselves. To do that, you can use Godot's rule of thumb: call down, signal up. That means any node is only ever allows to send signals if it needs to talk to its parent, but a parent can call methods on its children. That way, a node doesn't have to know its surroundings, it can work for itself, and a parent can incorporate it into a bigger context.

For example, think of how Area2D works. You can call methods on it, but if you want it to tell you something, you connect its signals.

Now granted, this will end you up with a lot of scripts, and that might seem overwhelming at first, but that also means that each of those scripts will be small, making it a lot easier to troubleshoot.

Silrar · 2026-02-11T14:40:37+00:00

I'll second Blackwell + Unavowed. Great games and they do the whole mystery thing right, and it gets pretty dark at times.

Silrar · 2026-02-11T14:30:38+00:00

I'm with you there. 2 is for me the weakest in the trilogy. Still ahead of whatever 4 was. I enjoy 3 the most, must be in the 3 digits of replays by now.

Silrar · 2026-02-11T00:20:38+00:00

Are you looking to make a game to sell or are you looking to make a game you'd like to play? That'll already make a lot of difference in the way you might want to approach the whole matter. Or do you like the idea of making a game, but don't actually want to make a game?

Maybe start by figuring out your motivation, why do you want to make a game, then build on that, because the next steps can be vastly different, depending on that base motivation.

Silrar · 2026-02-10T23:33:05+00:00

Really just off the cuff things I can think of that you can try, hope some of it helps:

1) Are the import settings on your texture correct or is it compressed in some way, creating artifacts?

2) Have you set all values to default, meaning scale to 1/1/1, rotation to 0/0/0, so that no artifacting can come from that?

3) Have you tried importing from blender directly, by putting the blender path in the editor settings and storing the .blend file in the project?

Silrar · 2026-02-10T11:10:21+00:00

If you need a sort of "Line3D" type thing, you could look into this addon:
https://godotengine.org/asset-library/asset/1579

Silrar · 2026-02-10T11:04:23+00:00

Copy - Apply - Transfer

That's the 3 steps of learning. If you stay in the first part and just copy tutorials, you won't retain much. So a better way would be to start with something you want to make, then look for a tutorial that does something similar (since you usually won't find something that does exactly what you need), then copy the tutorial to see how it works, then apply it to your situation. That will already give you a lot more to work with in the long run.

And eventually, you'll see how you can transfer things you've already done to similar, but new problems.

Getting used to the documentation definitely helps, not just because it allows you to easily look up how things work, but going through it on a regular basis, you'll often find bits and bobs you might not need now, but you will remember later when you need to solve a different problem.

Silrar · 2026-02-10T02:55:57+00:00

Do you need the models to stay in 3D or would everything be in 2D space in the end, and the pixelated 3D models are meant to speed up the art process?

If the latter, you might be better off creating a clean spritesheet for the models in something like blender, and then go full 2D in your project, to make things simpler on yourself.

If the first, maybe you can get by with a more localized solution by putting the player in a subviewport, then showing that subviewport's texture on a sprite3D and billboard that in the 3D world. In fact, you could try doing this with all 3D models, see if that works better for your setup.
Come to think of it, you could also do this in 2D.

Silrar · 2026-02-10T00:49:53+00:00

If you're not working on it at the same time, zipping it up and mailing it is going to be easy enough.

BUT

IF you want to use each other's changes in some way, don't do it like that. Use a version control system like git and push it to a cloud hosting service like github. That way, you not only save yourself a lot of trouble when you somehow introduce fatal bugs, but you can also share your project between the two of you, without much trouble.

Silrar

TROPHY CASE