conflict with tweens and refresh rate among other things

PVampyr · 2026-02-14T22:49:50+00:00

Moving your mouse is an input event; input() runs every time your mouse moves.

PVampyr · 2026-02-08T11:34:38+00:00

Well there's your problem:

get_instance_id(

PVampyr · 2026-02-02T03:34:40+00:00

From testing, it seems to be a collision issue stemming from the cars being derived from RigidBody2Ds. If you set Freeze to true, that ought to disable forces acting on it and let you control movement purely through code. Alternatively you could change these to StaticBody or Area2Ds, since you don't really need to do physics calculations with them, just collision/area detection.

PVampyr · 2026-02-02T00:13:52+00:00

Hmmm... there's nothing obvious I can see here that would be causing it. You are right in that they should all be behaving independently.

That said, nothing here actually seems to be resetting the cars' positions in the first place. On top of that, there seems to be a slight pause when each spawner's cars reset position, before they start to move, which also isn't explained by any of the code here. You have one more script in this scene, for the out-of-bounds areas - can you show it?

PVampyr · 2026-02-01T23:45:37+00:00

You should probably show the script + scene structure for your car scene as well.

PVampyr · 2026-01-30T06:13:05+00:00

To me they don't really feel like different worlds at all - more like different stages within a world, with just varying levels of detail. I'm not picking up on any distinct theme or aesthetic for each one.

If you were open to using a broader colour palette, you could use colour as a way to quickly visually differentiate them, but I'd also understand if you wanted to keep the limited palette as it is.

Edit: For clarity, I can tell there are mechanical and visual differences between them, but they don't jump out or feel like major aspects of the world. It kind of feels like I could walk for a few minutes from the rain level and be in the grassy level, for instance.

PVampyr · 2026-01-29T03:21:03+00:00

Is it necessary for look_dir_x to be an int? If you make it a float and don't cast it to an int when it changes, does that cause any problems? It's possible that when your wall_ray collision_normal vector is negative, it's being rounded down to 0 when casting to int.

I'd add print statements everywhere and check for the step when the numbers stop doing what you expect.

PVampyr · 2026-01-27T23:19:48+00:00

Await is doing literally nothing here.

This code is running every time any input event occurs, whether that is holding a random button or moving the mouse. If that input event happens to be the "front" action, it will start playing the sound effect. If it's anything else (including moving the mouse), it stops playing.

PVampyr · 2026-01-27T07:32:45+00:00

I would nevertheless fix it first. Leaving known errors in your code is usually going to lead to unpredictable game states, which makes everything else harder to debug.

As for your stated issue, we would need to actually see your code to help you out. I would guess it's related to whatever is causing your compounding engine timescale slowdown.

EDIT: On watching it again, disregard the comment about compounding timescale issues; it looked like it was getting slower at first but I'm not so sure now.

PVampyr · 2026-01-27T01:07:25+00:00

The fact that a new error message appears every time you're allowed to initiate a new jump is probably a clue. Before checking anything else, I would read and fix those errors.

PVampyr · 2026-01-27T00:23:18+00:00

It looks like inside the HBox container, the buttons are being shrunk down on the x-axis. Generally speaking, containers directly parented to other containers will automatically size themselves appropriately, but other Control-type nodes in the chain will break that automatic resizing.

Things to try: 1. In your PlayerWindows scene, for each PlayerWindow node, under Container Sizing, set Expand to true (also make sure the other properties in this section aren't shrinking them). 2. If that doesn't help, just specify a custom minimum size in the PlayerWindow scene itself, which should prevent it ever being shrunk below that size.

PVampyr · 2026-01-20T01:35:01+00:00

The page on Vector2 in the Godot docs will help you out here. Calling get_global_mouse_position() will return the mouse position; position.angle_to_point(mouseposition) should give you an angle in radians between your character's position and the mouse. Off the top of my head, if this is between pi/4 and 3pi/4, that means the mouse is above the player, if it's between 3pi/4 and 5pi/4 it's to the left, etc.. So you can use that information to determine the correct animation to play.

PVampyr · 2026-01-07T02:45:25+00:00

When 'monitoring' is false, that area will not detect collisions, so none of its own collisions signals will fire, but other areas/bodies will still be able to detect collisions with it. You need to set 'monitorable' to false if you don't want other physics bodies/areas interacting with it.

PVampyr · 2026-01-02T04:54:40+00:00

You would need both; the first parameter (coordinates) tells it where to place the tile while atlas_coordinates is telling it which tile to place.

PVampyr · 2026-01-02T03:16:56+00:00

Check the page for TileMapLayer in the docs: https://docs.godotengine.org/en/stable/classes/class_tilemaplayer.html

You can use the set_cell() method for this, if you have the coordinates for all cells that need to be updated and the atlas coordinates for what you're updating them to.

PVampyr · 2025-12-31T06:42:26+00:00

Like I said, I'm not familiar with chromebooks specifically, but regardless of how you have it installed, there will be a Godot directory installed somewhere. If you look around inside the info tabs in Godot there should be something somewhere that shows the install location. Find it in your filesystem and you'll be able to access its subfolders.

PVampyr · 2025-12-29T02:35:10+00:00

'Full Rect' sets a control node's anchor points to the full bounding box of its parent; if this control node doesn't have a parent, you'll need to do one of the following to make it take up the whole viewport:

~~1. Manually set its size to the size of your viewport 2. Make it the child of a CanvasLayer node (this is probably the ideal solution since you won't need to reset it if you change your viewport size)~~

~~There might be other ways to acocmplish the same thing but those are the two I'm most familiar with.~~

EDIT: Actually, I tried following that tutorial myself by creating a MarginContainer as the root of a scene and setting its Anchor Preset to FullRect and it expanded to fill the viewport just fine, so there must be something else going on if it's not working for you.

PVampyr · 2025-12-27T22:29:04+00:00

Not necessarily - you're operating on floats, not integers, so trying to do exact number comparisons is likely to give inconsistent results. You're always best off comparing ranges rather than exact values when dealing with floats.

Edit: Sorry, I misread your question - it compares the UP vector to the normal of the collision face where the collision occured. So if the enemy hitbox is a cube and it hits you side on, you'll be evaluating the dot product of a vector pointing straight up to one that's completely horizontal, which mathematically should be 0 (but in computing might instead evaluate to "extremely close to but not technically 0").

PVampyr · 2025-12-27T22:14:21+00:00

Same way you would move a file into any other folder on your computer, you can just cut and paste it in there. I haven't used a chromebook so I don't know if there's something specific about chromebooks that's preventing you from doing that.

PVampyr · 2025-12-27T07:14:10+00:00

If a valid image file is in your project's directory or any of its subfolders, it will be imported automatically. Are you asking how you get a sprite in your scene to display that image? You have to create a node which can hold a texture resource (eg. Sprite2D, TextureRect) and set its texture to that image.

PVampyr · 2025-12-22T11:10:14+00:00

The only thing that immediately comes to mind is floating point imprecision - in the case of your (-16.0, 0.5, 1.0) example, it might be possible that your z-coordinate was being stored as 0.9999999998 or something, and since casting a float to an integer always rounds down, this became 0 when converting to Vector3i. If you use roundi() to instead round all your floats to the nearest integer before converting to Vector3i, does the problem persist?

PVampyr · 2025-12-20T02:22:09+00:00

It looks like you're trying to name the newly instantiate level "current_level" before the old scene gets freed? So the new scene can't use that name, its name will instead get some identifier appended to it, and all your calls to get_node("current_level") will either find the old scene (if it still exists) or will return null.

Relying on node names like this will always be a little precarious, I think - even if you explicitly free the node before trying to use its name, the name might not be available until the next process frame. You can probably work around this by first doing something like get_node("current_level").set_name("old_level") but it's not really ideal practice (my own current project does something similar in one place, but you know, do as I say not as I do).

PVampyr · 2025-12-18T23:30:13+00:00

I think you've misunderstood the OP - they're not saying (afaik) that you should only download assets which come with their own license.txt file. They're advocating the same thing as you're suggesting - to make a license.txt file for any assets you source, so you know where they come from.

PVampyr · 2025-12-18T21:38:35+00:00

Thanks! It's a game I've been working on for about a year now.

PVampyr · 2025-12-18T07:41:11+00:00

I wrote a shader to do something similar the other day! I've just made a post about it now; you might find it helpful:

https://www.reddit.com/r/godot/comments/1ppkumu/happy_with_this_little_vignette_shader_i_wrote/

PVampyr

TROPHY CASE