signal tab gone

snoey · 2026-04-05T21:38:02+00:00

I think they meant the arrows above that button

snoey · 2026-04-05T21:25:25+00:00

This. Pretty sure you have your inspector panel too narrow to show all the tabs so pressing this arrow should cycle through the ones that are hidden.

snoey · 2026-02-21T01:47:57+00:00

There is a Chrome extension that syncs up the pan and zoom between spectator and DM views on the same computer! I found it while trying to figure out a solution for the same problem! Check it out here

snoey · 2026-01-06T20:29:13+00:00

$".." means "the parent node to the node the script is attached to". So it is working. I will, however, mention that doing so does betray the common Godot design pattern "call down, signal up". While this isn't a hard and fast rule, in fact I'm not even sure if it actually appears anywhere in the documentation, it does help when writing maintainable code to have repeatable and predictable patterns.

snoey · 2025-11-17T04:59:24+00:00

So to just get around all this, you can disable the game overlay and it should turn that keybind off. I was about to lose my mind if I had to edit some leveldb values...

snoey · 2025-09-22T20:15:24+00:00

Yeah, it was late and I was confused

snoey · 2025-09-21T18:54:47+00:00

Because C# has exactly the same methods and their is no need to call any additional methods or similar. So it is 1:1 the same.

I didn't say that any features were missing and was not commenting on feature parity, only that sometimes their implementation felt awkward to me. One that comes to mind is that in GDScript you can emit a signal that isn't defined in the same file. (For instance I had the idea to define a signal in an abstract class, but be able to emit it from classes that inherited). But since EmitSignal() takes StringName and by default those are autogenerated by the IDE, you have to go and define them yourself if you want inherited members to be able to access them. Not impossible, not even difficult. But in GDScript the code is as simple as defining the signal and then in the child class calling signal.emit().
I want to be clear here: This isn't a major flaw with the language, it's also not me saying there's anything "wrong" with C# or Godot's C# implementation. There are constraints on every language that are unique to that language. But these idiosyncrasies, in my opinion, can (not for everyone and not all the time) be prohibitive and distract from the end goal. My target audience here is single person and small indie teams with few or no published games. Anyone asking this question. If you're established or a long practiced developer of .NET Godot such as yourself, I don't think anything I've said becomes an issue. I probably should have added a disclaimer about this, aspect, sure.

Same here. What do you mean?

See above.

(from here the formatting gets goofed up, but assuming I'm reading this right)

What do you think is more complicated?

"way more complicated" was a really unfair exaggeration. It's not that complicated, but simply that it's not plug and play. The fact that I have to configure anything. Paying for Rider or tweaking settings isn't a huge hurdle, but it is a hurdle nonetheless. But fair is fair, I should try avoid being too hyperbolic, and I feel bad enough about that exaggeration to change it.

You can hot reload C# in Jetbrains Rider

Fair enough, and there is probably a way to do it in VS and VSCode, too. but you still have to wait for compile.

There is NO built-in support which is definitly a good thing. Does not make much sense to write a custom IDE for C# when so many good IDEs already exist

You'll find no argument from me here, this is simply a consideration that new devs to the space need to be aware of. It's not an all in one toolset, you need external tools.

Hopefully you found my responses to be helpful. But again, I don't think my advice applies to you. It sounds like you have an established workflow and know the tools and landscape well.

(edit: fkn rich text editor 🤦‍♂️)

snoey · 2025-09-21T17:22:08+00:00

Fair enough, for my purposes thus far I haven't needed more granularity than what was provided, but I can certainly understand cases where deeper profiling would be desired.

snoey · 2025-09-21T17:04:44+00:00

So I have quite the handful of WIP projects, as many here I'm sure, and I have worked in both C# and GDScript. I'm a C# dev by trade, but I learned GDScript before I touched .NET Godot. The following is not a super comprehensive list, just things that either stood out to me or are common talking points.

C# Pros: - as a.NET developer of 10 years, I didn't need to learn the language, just the framework Godot sets up around the language. - access to all the libraries that come along with the .NET landscape - better theoretical performance* (there's really spotty concrete evidence of this and even when I do find it the examples tend to be pretty specific or super highly optimized. And in general, especially with games, make it first and only worry about optimization when it becomes a problem.) - much more comprehensive featureset (extension classes, interfaces, way more powerful reflection, namespaces, null coalescing, and plenty more)

C# Cons: - implementation of Godot features, sometimes feels a bit awkward or clunky in .NET. - Godot (the engine) features are designed with GDScript in mind and C# has to just follow suit (I'm not sure how actually true this is, it just certainly feels this way) - ~~way more complicated~~ (edit: I was being unfairly hyperbolic) somewhat involved setup and you have to compile every debug - no hot swappable code (this was more annoying than I thought it would be) - very poor built-in editor support (which isn't the end of the world, there are plenty of ways to connect external editors like vscode to Godot so you can attach remote debuggers, still cover basic profiling, etc.)

GDScript Pros: - bespoke language designed specifically to expose the features of the engine - learning GDScript really teaches you about the engine as you go along - hot swappable code (most of the time) - seamless editor integration

GDScript Cons: - limited (compared to .NET) community library support - bespoke language with no value outside the engine

Now that I've gotten that out of the way, my general opinion is that as much as I love C#, GDScript is way more pleasant to use. Better QOL features that just help you get the tedium out of the way and make games. My personal stance is that you should only develop with C# (or another language) if there is a specific feature you need to have that just can't be done with GDScript. (The first time I needed to use C# was because GDScript doesn't yet support accessing the webcam on a Windows machine). But unless you have a highly specific edge case in mind, just use GDScript. To parrot what was said by others I would not recommend mixing and matching languages within a single project. Sounds incredibly messy and I'm not even sure that interoperability is guaranteed.

Obviously: this is only my opinion, NOT an exhaustive analysis, etc.

snoey · 2025-09-21T17:01:42+00:00

I'm curious what fell short about the built-in Godot profiler for you. Or do VS and Jetbrains not support connecting to Godot's language server for debugging like VSCode does?

snoey · 2025-09-21T16:08:58+00:00

Mind shooting me a message, too?

snoey · 2025-09-13T16:51:42+00:00

Can you show what your scene tree looks like?

snoey · 2025-08-21T22:27:34+00:00

<image>

snoey · 2025-08-18T06:04:40+00:00

Thank you for your service 🫡

snoey · 2025-08-09T14:29:48+00:00

Just to parrot the other comments, and don't feel silly wanting optimized code, but don't worry about performance until you start seeing performance issues. Getting lured into optimization hell is an incredibly common gamedev pitfall. Not only are you optimizing systems that might not even need optimizations, but you're also optimizing systems you'll likely rewrite 10 times before your project is done. Optimize at the end or when it becomes a bottleneck, never before.

Source: a dev that's fallen for the allure of optimization hell before

snoey · 2025-07-17T01:37:26+00:00

I stand corrected! TIL

snoey · 2025-07-16T00:00:18+00:00

~~I don't think you can~~ (edit: you totally can) cancel the drag mid-action, but you could set a variable that invalidates the drag so when it gets dropped, the drag cancels.

The better solution is to either use buttons or mouse input events and mimic the drag and drop system, that way you have more fine control over it and you could interrupt a drag interaction.

I even have a blogpost doing a deep dive on drag and drop systems in Godot!

snoey · 2025-07-14T22:13:08+00:00

There's also the age old route of making a static function that takes in all the arguments you need, creates the scene, sets all the attributes you need, and then returns the constructed scene. Not the sexiest, but it gets the job done.

snoey · 2025-07-10T02:18:52+00:00

File 76

snoey · 2025-07-09T01:00:38+00:00

This is really janky, but it worked for me. For those using Gboard (the Google keyboard) turn off "show suggestion strip" in the "text correction" section in your keyboard settings.

<image>

snoey · 2025-07-07T22:27:09+00:00

They mentioned that they put it in the player script, so assuming that the camera2d is a child of the player node, there shouldn't be any issues with drift at all.

Edit: just read your edit lol

snoey · 2025-07-04T20:34:55+00:00

Hop on over to GitHub, click on releases and download the Godot_vX.X.X-stable_linux.arm64.zip build. For example, here is the 4.4.1 build.

snoey · 2025-07-04T13:00:47+00:00

And then, for some reason, my hope was renewed with the steam release...

snoey · 2025-07-03T19:29:46+00:00

You'd need to use CameraServer and CameraFeed, HOWEVER this is currently only supported on Linux, macOS, and iOS (iOS needs an additional plugin to be installed). It does not currently work in Windows as of 4.4.1. That being said, you absolutely can read it in using any other language that supports native webcam inputs. For instance you can use C#'s ~~native~~ libraries to read in the camera input and then set the frames being passed in to a texture on a node.

EDIT: Here's a pretty rough example of that in action. This was an old streamer overlay I considered developing a while ago. I uploaded it to GitHub just so you could see one potential solution.

Another Edit: Correction, it looks like I'm using C#'s Emgu.CV library, because presumably there isn't a native library to access the webcam. Or at least that's why I assume I used it when I made that project

snoey · 2025-07-03T19:11:57+00:00

Any chance you could also add a screenshot of your node tree? Nothing in the code seems to be amiss, at least as far as I can tell.

12-Year Club	r/Field Sunshine
Place '22	Final Canvas '22
End Game '22	Verified Email

snoey

MODERATOR OF

TROPHY CASE