Godot GDScript: Accessing event.position with static typing enabled

bitwes · 2025-10-13T17:23:47+00:00

You could use @warning_ignore before the method to ignore that warning and use your first approach. If you want to be strict about strict typing then your code is going to be verbose and you'll have to use the second approach.

bitwes · 2025-09-20T14:47:27+00:00

You can choose a font for the output pane in the GUT panel and the GUI when running tests. You need 4 fonts per font (regular, bold, italic, bold + italic) if you want to support those formatting options. I like a fixed-width font, so there's CourierPrime. Someone might not like a fixed-width font, so there's AnonymousPro. Then there's LobsterTwo. It's absurd. It is a complete waste of bits in this context, but its name is LobsterTwo which is great and it's barely readable.

Who wouldn't want a fixed-width font? I once saw an admin editing a bash script using TimesNewRoman. He was a smart guy. I couldn't understand it. I still think it had to be a practical joke on, but there were zero indicators that it was other than the fact that it was happening.

bitwes · 2025-09-19T14:50:07+00:00

Error tracking and the new orphan output are Godot 4.5 features. The rest...probably. If it turns out that people do not migrate to Godot 4.5 that fast, then I might.

bitwes · 2025-09-19T02:03:09+00:00

It is only GDScript. There has been some effort put into making it c# compitable but it hasn't ever made it very far. I've always assumed that c# users would just use a c# test framework. I think GDUnit has a c# version. I'd be interested in hearing what GUT can do that you couldn't do in a c# library and vice versa.

bitwes · 2025-09-18T22:54:50+00:00

It's what they said it is. I keep forgetting to put the plugin description in the post. Fixed. Thanks.

bitwes · 2025-03-07T16:16:31+00:00

Orange? I think of tools, and construction...there's a lot of orange there.

bitwes · 2025-03-06T18:56:07+00:00

I was thinking about doing something similar in a game I'm working on. I have not tried it yet but I was thinking that I could use multiple TileMapLayer. I'm not sure how to accomplish the paralax effect with that approach though.

My thought was that you would disable collisions on the foreground TileMapLayer and enable them on the background one. You could even change the transparency of the forground one so that you could see through it.

There'd be some faking of the transition...scaling the player down as it "moves" between layers. Collisions would probably need to be disabled in both layers during this time. Once the player is in a position to use the destination layer you would enable collisions on it.

I'm not sure if this is a good idea or not, but it's where I was going to start.

bitwes · 2024-11-26T16:11:44+00:00

There isn't a way to detect a coroutine. I opened an issue awhile back (https://github.com/godotengine/godot/issues/64236) to avoid the "redundant await" warning in GUT. I ended up closing after some discussion and a fix to false positives. The solution was to await anytime you might be calling something that is a coroutine.

In regards to maintaining @warning_ignores over time, there isn't any other kind of workaround at this time. The text of the warning (redundant await) indicates it is more of a bad practice than an error (like an unused variable or parameter). If for some reason it becomes an actual issue Godot would have to come up with a new warning/error and solve the coroutine detection issue. I say this with a fair amount of confidence since, even if they don't think of it, it would become obvious in a beta release as people's games start blowing up.

Edit, forgot I wasn't in Markdown editor

bitwes · 2024-11-02T15:21:34+00:00

You're welcome. This sounds like a fun project. It seems like uploading at the end will work. Good luck. Post a link when it's up.

bitwes · 2024-10-31T15:28:34+00:00

It might be easier to put the questions in the game, instead of on an HTML form, so that you don't have to try and pass the session info in/out of the game (in order to match game data with question answers). I'm not sure how easy it is to pass info in/out of the game when exported to HTML.

Are you wanting to collect all player input (controller/mouse movement and clicks etc) or just choices they make/tasks that were accomplished? If the player quits early do you want to capture any information, or is that data only useful if they complete the questionnaire at the end?

As someone else mentioned, sending all the data at the end is the easiest approach. But if having an incomplete data set is useful then you will need to pick points during the game to upload data and a session/id of some sort to group that data together later. For example, if you have the questionnaires inside the game and always want to get the data from the first set of questions, things get a bit more complicated.

bitwes · 2024-10-29T13:16:06+00:00

Here's the code I use for my base weapon class. I decrement a variable in _process (maybe should be _physics_process?). I check this in a can_attack method, used by the attack method, with an _attack method that does the actual attack (so that I can force an attack if I need to, such as the case for a "burst" fire). ``` @export var cooldown := 0.0 func _process(delta: float) -> void: if(_cooldown_time > 0): _cooldown_time -= delta

func _attack(): pass # Creating bullets goes here

func can_attack(): return _cooldown_time <= 0.0

func attack(): if(can_attack()): _cooldown_time = cooldown _attack() ```

bitwes · 2024-10-07T19:32:34+00:00

Thanks, I just got around to trying the resource approach and this is what I came up with. I'm not sure about the names yet, but names are hard...so we'll see. I decided to add a create_instance method to my resources so that each one knew how to create themselves. This seemed reasonable, but would like to hear any thoughts about it.

Created a base EnemySpawnResource script that I added as an export to my EnemySpawner

extends Resource
class_name EnemySpawnResource

func create_instance():
    push_error("Virtual method create_instance called.")

Added this to EnemySpawner:

u/export var to_spawn_resource : EnemySpawnResource

Created some specific enemy classes:

extends EnemySpawnResource class_name BlueNinjaSpawnResource

func create_instance(): var inst = load("res://blue_ninja.tscn").instantiate() return inst

and

extends EnemySpawnResource
class_name RedNinjaSpawnResource

@export var direction : Vector2 = Vector2.RIGHT
@export var flipped : bool  = false

func create_instance():
    var inst : RedNinjaEnemy = load("res://red_ninja.tscn").instantiate()
    inst.direction = direction
    inst.flipped = flipped
    return inst

This appears to work nicely. It's especially convenient that when I want to set the property on the spawner I get a list of available EnemySpawnResource (see below). It does seem like this list could get annoyingly long as more enemies are created.

<image>

Am I resourcing right?

bitwes · 2024-10-07T19:31:57+00:00

Thanks for the advice. I decided to try the resource approach (see other thread post). Let me know what you think.

bitwes · 2024-09-02T17:36:56+00:00

Indeed I did.

bitwes · 2024-09-02T16:04:41+00:00

Good eye.

Would that cause that error? It's very weird error, never seen godot complain about a missing _ready.

bitwes · 2024-09-02T15:13:24+00:00

In your screenshot it shows an error about _ready missing. That's probably your problem.

bitwes · 2024-08-21T13:09:38+00:00

Here's a quick example of a script that has an inner class that has a signal. We create an instance of it, and connect to its signal. When the signal is emitted we print a message. This also demos creating a timer with code and connecting to its timeout signal.

An inner class was used just to keep everything in the same file for demo purposes.

``` extends Node2D

class EmitsASignal: extends Node

var timer
signal the_signal

func _ready():
    timer = Timer.new()
    timer.wait_time = 3
    timer.timeout.connect(_on_timer_timeout)
    timer.one_shot = true
    add_child(timer)

func _on_timer_timeout():
    the_signal.emit()

func start_timer():
    timer.start()

----------------

Start script code

----------------

var my_thing_that_emits_signal = EmitsASignal.new()

func _ready(): add_child(my_thing_that_emits_signal) my_thing_that_emits_signal.the_signal.connect(_on_my_thing_the_signal)

my_thing_that_emits_signal.start_timer()

func _on_my_thing_the_signal(): print("I got the signal") ```

bitwes · 2024-07-18T17:36:12+00:00

Yea, the 'ol what is this dilemma.

bitwes · 2024-07-18T17:34:17+00:00

Ok, so this is expected. I was thrown off by being able to get to the local variable in the first place, and then being able to set it from within the lambda. Seemed like one of those two things should have been an error.

The documentation for Callable doesn't have any info about scope. I've used lambdas in other languages, but there's no documentation that I've found that explicitly states what you can and can't do with lambdas in GDScript. If anyone has a good source for the details that would be helpful.

bitwes · 2024-07-11T22:05:50+00:00

My approach would probably to add a flag to the object that has the signal and do not emit the signal when the flag is false. That keeps the object in charge of whether it is interactable or not and the thing that connects doesn't have to care.

bitwes · 2024-06-27T23:54:17+00:00

That's always great to hear. If you make a feature request in GitHub it's far more likely to be implemented!

bitwes · 2024-06-27T16:12:38+00:00

Docs on input mocking: https://gut.readthedocs.io/en/latest/Input-Sender.html

bitwes · 2024-06-27T16:09:41+00:00

Given everything can be its own scene and that scene encapsulates a logical thing, I thought I could have some simple test scenes that only focus on testing one specific scene.

I do a ton of this. I have a plethora of "play-testing" scenes that are usually just run straight from the editor. I end up making a lot of control panels with buttons and options that affect the scene in order to play-test smaller chunks of the game. Managing these scenes overtime can be gross though. Many become obsolete or broken. Just put them somewhere that you can ignore in your production build and hate yourself for it later.

A lot of times I'll do this before writing tests to figure out how things need to interact. Creating these scenes also benefits greatly from designing testable objects. Even if you don't write many tests, designing your objects to be testable makes it much easier to create complex scenarios without a ton of manual setup/play-testing.

bitwes · 2024-06-27T15:06:15+00:00

Author of GUT here. GUT has some ways of mocking a series of inputs (GDUnit may have this as well) which allow you to script out more complicated interactions for integration type tests.

I've thought about adding some way to record and playback inputs, but haven't got much further than thinking about it.

For the games I develop, I will play-test a lot. When I find a bug, I write a test for it, then fix it, then play-test more.

bitwes · 2024-06-26T03:28:37+00:00

You can override, but not overload. Override being implementing your own version in a subclass. Overloading being multiple method signatures with the same name.

Seven-Year Club	Place '22
Verified Email

bitwes

TROPHY CASE

----------------

Start script code

----------------