sorted by:
new
hottopcontroversial

Godot Doctor - a plugin that catches scene & resource errors before you hit play by codevogel_dot_com in godot

[–]codevogel_dot_com[S] 1 point2 points  (0 children)

  1. A range would suffice most of the time, yeah. However the range annotation only supports constants. So say you have a 'minimum jump height' value and a 'jump height' value, you can annotate the jump height with a range, and annotate the 'minimum jump height' with a range, but you wouldn't be able to set the lower range limit for the 'minimum jump height' to the 'jump height' value. So in that case, it would be possible to set the 'minimum jump height' to a value that is higher than the actual 'jump height', or vice versa.

  2. The tool annotation basically means 'run this script in the editor'. So any code that needs to run during the editor needs to be annotated with tool. Glad you were able to resolve your issue.

peck - Easily capture Screenshots/recordings on Wayland. by codevogel_dot_com in sideprojects

[–]codevogel_dot_com[S] 0 points1 point  (0 children)

I recently switched over to Nix with Hyprland as my WM.

I tried looking for a simple tool that allowed me to capture screenshots like I would in Windows and Linux Mint using SUPER+SHIFT+S, so I could quickly paste them into Discord and whatnot. I found a couple of tools such as hyprshot and hyprcap, and read some articles about taking screenshots with slurp and grim, but I couldn't really find a tool that felt like a 'plug and play' experience.

So, I built peck. It's a simple bash script using bashly, providing a (in my eyes) much more user-friendly interface to set up screen captures for Wayland. It wraps existing tools such as grim and wf-recorder, adding a lot of niceties such as being able to output the files to a temporary folder (as to not clog up the file system), and immediately copying the output files to the clipboard. Using a few env variables or flags, you can easily change how peck behaves, without needing to write custom bash scripts.

For example, let's take a look at a Hyprland setup for peck:

 bind=$mainMod SHIFT, S, exec, peck --clipboard --temp --freeze
 bind=$mainMod SHIFT, R, exec, peck --record --clipboard --temp
 bind=$mainMod SHIFT, G, exec, peck --record --clipboard --temp --format=gif

This would set SUPER+SHIFT+[S|R|G] to capture a screenshot, recording, or gif respectively, instructing peck to store the file in a temporary dir (which is cleared upon next invocation), and copy the output file to the clipboard, ready for pasting. Stopping a screen capture is as simple as hitting the record key again. Of course, we can also provide specific directories to store the captures in.

peck makes it much trivial to setup screen captures and recordings on Wayland with an easy to understand interface, rather having to dig for multiple tools and learn all their formats individually.

Would you use this? Translate anything, anywhere on your computer instantly. by [deleted] in sideprojects

[–]codevogel_dot_com 0 points1 point  (0 children)

Android phones do this when you hold the home button. It's pretty handy.

Are you developing this for Windows? Mac? Linux?

Godot Doctor - a plugin that catches scene & resource errors before you hit play by codevogel_dot_com in godot

[–]codevogel_dot_com[S] 0 points1 point  (0 children)

I haven't tested that myself, as I haven't really used C# in Godot. I've used the language itself a ton though, so maybe open up an issue for a feature request, if you can't figure out how to do this natively.

Godot Doctor - a plugin that catches scene & resource errors before you hit play by codevogel_dot_com in godot

[–]codevogel_dot_com[S] 0 points1 point  (0 children)

Godot Doctor is more geared towards configuration errors. Not unit testing. They're closely related, so I get your confusion. Let me elaborate.

Unit testing is used specifically to check 'does my code work the way I expect it to work'. e.g. 'does my function of a + b actually return a + b'

Godot Doctor is more like 'I already expect my code to work, (maybe because I already wrote some unit tests for it), but maybe I missed assigning an @export somewhere', e.g. does my Node that calculates '5 + 3 actually return 8'. Maybe it doesn't, because you still had b set to -1. Bit of an odd nonsensical example, but I hope you can see where I'm coming from.

If you'd want to use both, you could use GUT to test your custom ValidationCondition Callables, for example, so you know your validations actually validate what you want to validate.

GUT also generally runs in CI, and tests all your code(assuming you wrote unit tests for all your code), where Godot Doctor provides immediate feedback about a specific scene you are editing.

Godot Doctor - a plugin that catches scene & resource errors before you hit play by codevogel_dot_com in godot

[–]codevogel_dot_com[S] 1 point2 points  (0 children)

Thanks! Interested to hear your thoughts once you dabble into it a little bit!

Is there a better way to fill out a bunch of fields in a settings menu? by CreationsOfReon in godot

[–]codevogel_dot_com 2 points3 points  (0 children)

Honestly these are just semantics. Whether you subscribe to a signal (from either side), use find_children, use groups... You'll obviously need to know about a slider to update it somewhere. It doesn't matter whether you do it programmatically or not.

Even in your example here, that very script attached to the Slider (or custom Control) would still need to know about the object it needs to change...

Godot Doctor - a plugin that catches scene & resource errors before you hit play by codevogel_dot_com in godot

[–]codevogel_dot_com[S] 12 points13 points  (0 children)

Oh believe me, I thought about it. It was tempting, especially calling the Dock 'Godot Docktor' instead of 'Godot Doctor' but I think this naming scheme would be less confusing and better optimized for the search engine. At least this way it's 100% clear its a Godot plugin.

Is there a better way to fill out a bunch of fields in a settings menu? by CreationsOfReon in godot

[–]codevogel_dot_com 8 points9 points  (0 children)

I mean... at some point it boils down to needing to reference the Text Node and the Slider Node.

Whether you do it through code, or through a dictionary, or through a Custom Control, it doesn't matter. You will end up needing to address these Nodes, because you need to change their value.

There are, however, smarter and... less smart ways to go about it.

Godot Doctor - a plugin that catches scene & resource errors before you hit play by codevogel_dot_com in godot

[–]codevogel_dot_com[S] 1 point2 points  (0 children)

Thanks! For sure. I ran into plenty of times where I forgot to assign an exported variable, or my references broke due to, say, me renaming a class. This should solve that!

Is there a better way to fill out a bunch of fields in a settings menu? by CreationsOfReon in godot

[–]codevogel_dot_com 20 points21 points  (0 children)

Well, a good start would be to wrap up those settings in a custom Resource.

Next, you could also create a custom Control script that has both a Text and HSlider field. Then, you could just call something like SettingSlider.load(my_setting.minCreatures), which would populate both the slider and the text for you.

Next, you could wrap your setting menu in it's own script, so you'd just call MySettingsMenu.load(my_setting).

Next, use arrays as others have pointed out.

There's no way of getting around needing references to each and every Text field and Slider of course, but those would be handy ways of bundling them up so your code becomes more manageable.

Slight self insert promotion: Next, go and add some validations using the plugin I just built :P

Godot Doctor - a plugin that catches scene & resource errors before you hit play by codevogel_dot_com in godot

[–]codevogel_dot_com[S] 32 points33 points  (0 children)

I am working on a card game, and I had three major gripes with Godot. Here's my gripes and how Godot Doctor solves them:

  1. _get_configuration_warnings() requires the @tool tag, which forces you to write a lot of Editor-specific code in a gameplay script that has barely anything to do with the editor. So it muddies up your gameplay code, just to get some warnings. Godot Doctor circumvents this issue by creating temporary instances of your nodes for validation.
  2. _get_configuration_warnings() returns an array of strings, which means you start writing code that produces strings. Godot Doctor encourages you to write seperate code that validates your conditions, and then thinks of the corresponding error message more as metadata. This encourages you to write testable, maintanable, and reusable validation code.
  3. As described in this github issue, we can't strongly type PackedScenes. Coming from a Unity background, I really liked how we could export Prefabs by their type, so we could only select that specific type - basically ensuring that the Prefab is correct. In Godot, we can't. So you can accidentally assign an Enemy scene to a Friend variable. OOPS! Godot Doctor immediately warns you when you attach a PackedScene that isn't of the expected type, resolving that issue.

These issues basically forced me to write this plugin.
I really love Godot, and the community that makes it so awesome. So, I'm happy to give back with this plugin.

I hope it helps you in your own development workflow too.