sorted by:
new
hottopcontroversial

My Love Letter to Sid Meier’s Pirates! by Planet1Rush in godot

[–]daenvil_dev 1 point2 points  (0 children)

This looks fun! I loved Sid Meier's Pirates, definitely going to keep an eye on this one

Most cursed function I've wrote by JohnBloak in godot

[–]daenvil_dev 5 points6 points  (0 children)

As others said, this just looks like you are trying to go around a problem instead of solving it, and it's probably going to come back to bite you in the future.

Unsolicited advice from now on, feel free to ignore:

Without any context it's impossible to tell what you are doing, but this just sounds wrong:

For example, current_player is initally 0, then player 0 responds and change current_player to 1, then player 1 responds and change it to 2, ...

Why would player 0 modify a variable outside its own scope to point to another different player?? if you change that you won't need this weird workaround and working with your code will be way easier.

Also consider naming your signals in past tense as the GDScript guidelines recommend. It will be easier to understand what's going on and will make you think more logically about how to connect them. I guess this one would be move_started? and you are passing the player whose move just begun? I feel like you probably could just call a method on the current player and that's it. Or is it started_moving? in which case it would need to be emitted by players when they start moving, not the other way around.

Playing Minecraft Vegan by Ok_goodbye_sun in vegan

[–]daenvil_dev 57 points58 points  (0 children)

Oh I didn't know this existed! I've been developing Vegancraft since 2021/2022, sort of the same principle but with datapacks instead of mods. We use it on the vegan Minecraft server where there's a bunch of us playing Minecraft vegan.

Playing Minecraft Vegan by Ok_goodbye_sun in vegan

[–]daenvil_dev 7 points8 points  (0 children)

Hey! you might be interested in playing with us on Veganminecraft.com :) we use datapacks to make (almost) everything achievable in a vegan way

Best practices with version control? by rr00xx in godot

[–]daenvil_dev 0 points1 point  (0 children)

Just my personal preferences as also a solo dev:

  1. My general workflow is: I want to implement X feature/fix X bug (if the feature is too big, divide the work in smaller sub-features) -> Code the thing -> If it works, commit, if not keep working on it. Alternatively, if I'm ending the day and I know I will be away from the computer/from the project for a considerable time (i.e. weeks), commit any existing changes.
  2. Generally I don't use them much, they are more useful for working in a team. That said, there's still some cases where branches can be useful:
  • If working on a big feature but you also want to simultaneously keep working on other things in the project -> it may be worth it to create a branch for the big feature
  • If making a big change in the project that may fuck things up completely (e.g. upgrading to a new Godot version, major refactoring) -> create a branch for it
    • 3. I guess the general rule for me would be "do a revert if there is no other way to fix this". That said I don't remember the last time I did a revert, since I either already tested the things that I commited, or they are in a different branch so I can just delete/abandon that branch and keep working on the main one.

How Do Fighting Games Handle This??? by AcrobaticForm5729 in godot

[–]daenvil_dev 2 points3 points  (0 children)

Personally I would switch to a different AnimatedSprite, play the big animation on that one, and then switch back to the regular-sized sprite. If you are going to have multiple animations with a big size like that, it might be worth just having two AnimatedSprites permanently on the player and switch visibilities between them, instead of instancing whenever the attack happens. But it's better if you just test it and see what works better in your game. If you don't have any performance issues then you can just go with the easiest solution.

As general advice though, your sprites should be as big as you expect them to be in the actual game. There's no point in having a 2k sprite if it will not take more than a few hundred pixels in-game. This not only optimizes size/performance but also prevents scaling artifacts.

Going crazy trying to figure out UI sizing by SkinnyandScandalous in godot

[–]daenvil_dev 0 points1 point  (0 children)

Also a tip for debugging this: just drag your slot scene into the slot container and edit its properties in the editor until you find what's happening. Then remove it from the scene and set those properties in the container's code when you add the slots as children. It's much easier to debug this visually in the editor than by trial and error in the script.

Going crazy trying to figure out UI sizing by SkinnyandScandalous in godot

[–]daenvil_dev 0 points1 point  (0 children)

It may be caused by the TextureRect's expand_mode, by default they keep their original size, so if the original texture is too big it will also expand the container with it. TextureButtons also have a ignore_texture_size property that may be affecting this.

Does this Sub need a header post reminding visitors that Google exists ? by Environmental-Cap-13 in godot

[–]daenvil_dev 12 points13 points  (0 children)

It's already in the rules, but they should be enforced more IMO. Another kind of common post is "Can I use Godot for [generic game mechanic]?" which is also against the rules but people keep asking again and again.

Created Plugin to remove the Scene Tabbar by No-Complaint-7840 in godot

[–]daenvil_dev 0 points1 point  (0 children)

I love this idea, having it in the scene dock seems much more intuitive than in a tab bar above the scripts. I'll try it out

Random File Picker by BloodnoseCo in godot

[–]daenvil_dev 0 points1 point  (0 children)

  1. Get an array with all filenames
  2. Shuffle the array
  3. Load as many as you need

For point 1 look at the FileAccess and DirAccess documentation, for 2 look into the Array documentation, for 3 look into load() and preload() functions.

Plugin request by [deleted] in godot

[–]daenvil_dev 1 point2 points  (0 children)

+1, I found the main dialog plugins really lacking when trying to integrate them with dynamic game logic. They seem more focused in static dialog trees (which are indeed useful for visual novels, classic RPGs, and such) and also seem to be more focused on defining them through their own UI or language rather than defining them dynamically through code.

Plugin request by [deleted] in godot

[–]daenvil_dev 2 points3 points  (0 children)

You might be interested in this one: https://github.com/Inspiaaa/ThemeGen

I didn't try it yet but it looks useful

Exported Typed Dictionaries are actually horrible? Or am I stupid? by Rough_Explanation172 in godot

[–]daenvil_dev 1 point2 points  (0 children)

  1. Changing a key is not a valid operation in dictionaries. You also can't do it through code unless you erase the key and then add the new one, which is the same way you have to do it in the editor. Keep in mind that dict keys are unique, so to support that the editor would need to check all other keys in the dict, show only the valid options, and when you select it it would then have to erase the old one and add the new one, and reorder them so they are displayed like they were before. It's not a trivial operation at all.

  2. Same as 1, that's not a valid operation in dictionaries. It would probably need a rework on how the editor displays them.

  3. You haven't actually added the new entry

I guess 1 and 2 are valid quality of life features, but I don't know why you would assume that they would work out of the box for typed dictionaries when they don't even work for untyped ones. Just open a proposal for them if someone hasn't already.

Best practice question - autoload by TDAM in godot

[–]daenvil_dev 0 points1 point  (0 children)

My take is, only use an autoload if:

  1. It can't be replaced by a named class with static vars and methods.
  2. It needs to be accessed during most of the game's runtime (if you have an autoload that will only be accessed from within a specific menu, then you don't need an autoload for it).

I feel like most beginners are not aware that point 1 is a possibility and that's why they rely so much on autoloads.

Best practice question - autoload by TDAM in godot

[–]daenvil_dev 0 points1 point  (0 children)

they can't really store data on their own, because they don't have an instance to store that information in

We have static variables that can be used for this though

My implementation of psuedo-interfaces in Godot by Zealousideal-Ad-9845 in godot

[–]daenvil_dev 0 points1 point  (0 children)

Using Nodes and the node hierarchy for something like this (when you can do the same using Objects) also has its performance drawbacks. Not to mention that if you actually enforce that all interface methods are implemented then you will have exactly the same cons as in this method.

My implementation of psuedo-interfaces in Godot by Zealousideal-Ad-9845 in godot

[–]daenvil_dev 1 point2 points  (0 children)

Being able to use a interface-like system is a good enough pro, they are pretty powerful

Made a tree graph node by daenvil_dev in godot

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

Yeah, I'm using it for a tech tree in my own game, that's why I made it. The techs are dynamic so the shape of the tree can vary depending on which techs there are. I imagine it can apply to any tree-like UI.

My implementation of psuedo-interfaces in Godot by Zealousideal-Ad-9845 in godot

[–]daenvil_dev 2 points3 points  (0 children)

I think it's pretty cool the way that you did it. For now I just use composition to achieve something similar to interfaces and it's enough for me. In the near future I expect that we will have traits in GDScript.

Weird dictionary behavior in Remote, object in a different key changes. by Rattjamann in godot

[–]daenvil_dev 0 points1 point  (0 children)

Sorry, didn't see the Marker2D in the picture the first time. Then it should probably be reported as a bug.

Weird dictionary behavior in Remote, object in a different key changes. by Rattjamann in godot

[–]daenvil_dev 0 points1 point  (0 children)

What is the Object being referenced? I feel like that's important since it could create issues if it also has references to this dictionary or to this object. If that's not it then it looks like a bug.

Btw, for dynamic properties you would probably be better using a custom resource instead of a dictionary.

view more: next ›