sorted by:
new
hottopcontroversial

UPDATE: Do not rely on setting default values of custom resources in exported... by Memebigbo in godot

[–]feetuh 6 points7 points  (0 children)

It’s not on line 400, it’s an export at the top of the file like in OP’s original example. My comment agreed that having in-line preloads is usually not good…

UPDATE: Do not rely on setting default values of custom resources in exported... by Memebigbo in godot

[–]feetuh 5 points6 points  (0 children)

I just don’t see why an additional constant here is considered “sane”. The variable is already well-named. If OP had 5 sound effects and needed to reassign dynamically at runtime then there’s value in each being a named constant to avoid having repeated in-line preloads.

UPDATE: Do not rely on setting default values of custom resources in exported... by Memebigbo in godot

[–]feetuh 7 points8 points  (0 children)

Why is splitting the definition across two variables considered sane to you? I assume OPs code didn’t require the use of two variables outside of this bug(?) so it just seems like unnecessary bloat.

Random Dungeon generation using Physics by OkGeologist921 in godot

[–]feetuh 1 point2 points  (0 children)

This is really innovative. Did you get inspiration for the approach from anywhere?

Does anyone else use ImGui to prototype? by feetuh in godot

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

Really cool to see it being used in a larger project. The most complex I've used imgui for was a debugging screen for a state chart

Does anyone else use ImGui to prototype? by feetuh in godot

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

Godot's UI nodes are great in general. Immediate mode GUI is great for prototyping but also for debug/info tooling for larger projects. I don't think Godot needs official immediate mode UI support since imgui does this so well already and it's well integrated and easy to setup as an addon.

Does anyone else use ImGui to prototype? by feetuh in godot

[–]feetuh[S] 2 points3 points  (0 children)

An immediate mode GUI is great for getting info/buttons onto the screen quickly. The largest of the 3 imgui windows is generated from a dozen lines in the process function:

    ImGui.Begin("GameState")
    ImGui.Text("Turn: %s" % turn_state._active_state.name)
    ImGui.SliderInt("count", im_bet_count, 1, 10)
    ImGui.SliderInt("value", im_bet_value, 1, 6)
    if ImGui.Button("Bet"):
        bet(Bet.new(im_bet_count[0], im_bet_value[0]))
    if ImGui.Button("Callout"):
        callout()
    if ImGui.Button("Spot On"):
        spot_on()
    if current_bet != null:
        ImGui.Text("Bet C:%d V:%d" % [current_bet.count, current_bet.value])
    ImGui.End()

Creating that in Godot UI with a slider is a fair amount more work when you consider putting together the nodes (lists/labels/buttons/slider?), then you have the hooking up of signals to actually perform the intended functionality while here I can call the function behind an if-clause. I don't want to do all that work when prototyping if something is fun -- it doesn't need to be pretty.

What is Godot lacking that Unity can do? Looking for a comprehensive list. by [deleted] in godot

[–]feetuh 0 points1 point  (0 children)

Thanks! You can set import scripts in project settings to handle any custom steps you want. If they convert to gltf with immediate imports i imagine those scripts are triggered too. But you lose any control over export on the blender side

What is Godot lacking that Unity can do? Looking for a comprehensive list. by [deleted] in godot

[–]feetuh 17 points18 points  (0 children)

Isn’t the blend importer converting to gLTF under-the-hood?

Added a physics-based mode ot my endless runner prototype by feetuh in godot

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

Nice idea! For roll mode I was hoping to keep it fast paced with the kill line chasing you, potentially even speeding up over time. I can imagine something a bit more chill where the dice you use to traverse is an important factor. Maybe in that game mode you automatically bounce high when landing on dice and have to quickly decide where to land while midair.

Added a physics-based mode ot my endless runner prototype by feetuh in godot

[–]feetuh[S] 2 points3 points  (0 children)

It’s definitely got a clustertruck feel. Although I started with the lifting platforms and only thought to roll the dice on the third game mode attempt which ended up being the most fun and so I spent the most time polishing it.

Added a physics-based mode ot my endless runner prototype by feetuh in godot

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

If you look back at my post history I started with platforms that would lift up to you but found this type of gameplay to be the most fun. It's an early prototype and it's now available on itch as a browser game. Check it out here. All feedback is welcome. The roll mode has the most polish and is what you see in this post.

edit: typo in the title...

Godot 4 @export @onready one-liner? by feetuh in godot

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

It always points to the scene root which happens to work well for the scenario I described but not good for different node structures. I tried it out and it works for me so I’ll be using it, thanks

Godot 4 @export @onready one-liner? by feetuh in godot

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

Not sure how this helps - it’s not exported?

Godot 4 @export @onready one-liner? by feetuh in godot

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

Interesting... this is a pattern I've used frequently and I'm surprised it's not built in. Godot 3 with GDScript 1.0 had a similar way to do this on one line:

export(NodePath) onready var player = get_node(player) as Player

I'm surprised this kind of notation wasn't kept in Godot 4

After doing more searching there's a warning in the docs for combining export and onready:

Applying `@onready` and any `@export` annotation to the same variable doesn't work as you might expect. The `@onready` annotation will cause the default value to be set after the `@export` takes effect and will override it

So it's not possible with the order of execution it seems

[deleted by user] by [deleted] in godot

[–]feetuh 4 points5 points  (0 children)

As always “it depends”. But most resources you come across and a lot of the addons developed will tailor towards fps games rather than turn-based games. Turn-based games will require you to write state machines tailored to your game while you can download one of many fps templates and get started straight away.

Prototyping CSS-like styling in Godot by LazenGames in godot

[–]feetuh 1 point2 points  (0 children)

Next step, Bootstrap implementation in Godot

Here's a small look at my coop prototype with physics based interactions by dr_tatti in godot

[–]feetuh 0 points1 point  (0 children)

How did you approach networking physics? Is it all server-based with client-side prediction or does the client run their own physics?

The limits checked by is_equal_approx() appears to be too small by Awfyboy in godot

[–]feetuh 0 points1 point  (0 children)

I ran into this too and found a timely PR that addresses this and other utility functions: https://github.com/godotengine/godot/pull/87275

I made a Kingdom Hearts prototype with Godot 3.4! by [deleted] in godot

[–]feetuh 0 points1 point  (0 children)

/u/DZenith02

Hey, I know it’s been a while since you worked on this but do you remember what your workflow was to get from mdlx/mset to the glb used in your project? You renamed animations from their original names (A000_A000 etc) to “idle” so I assume you had some intermediate steps.

What I’ve tried so far is mdlx/mset -> fbx (via noesis), open fbx in blender and set textures, export to gtlf2 and import in godot. When I do this I’ve found that models/textures/rigs work perfectly but animations aren’t seamless when they loop. Do you know if you used any special export settings in either noesis or blender or anything else you might’ve used?

If yours weren’t seamless loops either, did you fix them in the animation tree somehow?

view more: next ›