text:
built-in seeding functionality

Describe the feature

I am proposing that Gorm has a built in Seeding method so that developers can quickly seed databases within gorm without having to re-create the functionality.
Example Proposed Usage:

// make class (or interface) that is the same shape as your database
type person struct {
    name string
    age  int
}

// create an array of 'dummy' data using the object
seedArray := [3]person{
    {
        name: "John Doe",
        age: 18
    },
    {
        name: "Jane Doe",
        age: 22
    },
    {
        name: "Steve Doe",
        age: 32
    }
}

// pass the array into a seeding method
DB.Seed(seedSlice)

Motivation

Seeding is a required process during the development process, and during platform migrations.
Creating a seeding method will improve the developer's quality of life, and could increase the user-ship of GORM and GoLang as a whole.
Related Issues

Developers have asked if the functionality exists.
Issue 5274
Issue 1539
Some Developers have written Work around Tutorials
Tutorial

This sounds like functionality that should be done in a separate library and not as part of an ORM. Maybe an integration of the existing projects for seeding, like jaswdr/faker, with gorm, similar to datatypes, might be a better fit instead.

Seeding seems to not be the responsibility of ORM, however, you may try implementing it as a plugin. https://gorm.io/docs/write_plugins.html

authors: Chaostheorie TheMagicNacho saeidee


text:
fix: nested scan (#6136)

[X] Do only one thing
[X] Non breaking API changes
[X] Tested

What did this pull request do?

fix nested scan panic #6136
User Case Description
var user User
if err := DB.Scopes(func(db *gorm.DB) *gorm.DB {
	var maxID int64
	if err := db.Raw("select max(id) from users").Scan(&maxID).Error; err != nil {
		return db
	}
	return db.Raw("select * from users where id = ?", maxID)
}).Scan(&user).Error; err != nil {
	t.Errorf("failed to find user, got err: %v", err)
}

If this PR is only used to fix the panic issue in the nested scan, I think don't panic but return an error should be enough.
We don't expect users to use it like this, for more details: https://gorm.io/docs/method_chaining.html
Going this close this PR for now, feel free to create a new one if those changes are required in other scenarios.
Thank you.

source: gharchive/pull-request

repo: go-gorm/gorm

license: MIT

license_type: permissive

license_source: github-api


text:
Add CockroachDB Support

Because CockroachDB does not support the create schema syntax, an addition to the Dialect interface was necessary.

Hi folks, just wondering if anyone has time to revisit this?

authors: proffalken zikes

repo: go-gorp/gorp

license: mit

license_source: bigquery


text:
access logger: read status code from HTTPError, if returned by c.Next()

The access logger takes the status code, which is being logged, from the LogResponseWriter. If the c.Next() handler does not use WriteHeader, but instead returns a HTTPError, the access logger will log the request with a 200 OK status. (e.g. if serving static files and the requested file does not exist, status code in log will be 200 and not the returned 404)
To fix this, we need to check the error object returned by c.Next() and use its status code if available.

Coverage remained the same at 95.089% when pulling 1a17ad49edb50c9fa1a96c53c77f1e0acbbacd67 on studio-b12:master into 8c1099aeb3317626e959210556e96b0c77915b14 on go-ozzo:master.

You should use fault.Recovery middleware after the access logger. It will correctly handle the error and set response status code.

Thanks for your quick reply. With fault.Recovery it's working fine.

authors: coveralls kmsb12 qiangxue

repo: go-ozzo/ozzo-routing


text:
ykls panics when a non-YubiKey smartcard reader is present

The following occurs if I run ykls while my laptop's ExpressCard smartcard reader is in:
$ dpkg -x /opt/deb/buildarea/golang-pault-go-ykpiv-dev_1.3.2-1_amd64.deb .
$ ./usr/bin/ykls --help
Reader:  Gemalto GemPC Express 00 00
panic: ykpiv ykpiv_connect: PKCS Error (-2) - Error in PCSC call

goroutine 1 [running]:
main.ohshit(...)
	pault.ag/go/ykpiv/cmd/ykls/ykls.go:31
main.main()
	pault.ag/go/ykpiv/cmd/ykls/ykls.go:44 +0x7cd

After removing the reader:
$ ./usr/bin/ykls
Reader:  Yubico YubiKey FIDO+CCID 00 00
Version: 4.3.7
Serial:  6447364
Slot Authentication (9a): nicoo@debian.org

I have the same problem and in my case the PC/SC reader is also my main keyboard. So I can't disconnect it.
$ ykls
Reader:  Cherry GmbH CHERRY SECURE BOARD 1.0 [CHERRY SECURE BOARD 1.0] (00000002JS0405948M3DOGKTHA) 00 00
panic: ykpiv ykpiv_connect: PKCS Error (-2) - Error in PCSC call

goroutine 1 [running]:
main.ohshit(...)
	pault.ag/go/ykpiv/cmd/ykls/ykls.go:31
main.main()
	pault.ag/go/ykpiv/cmd/ykls/ykls.go:44 +0x7cd

One workaround is to use PCSCLITE_FILTER_IGNORE_READER_NAMES= as documented in https://ludovicrousseau.blogspot.com/2015/12/remove-andor-customize-pcsc-reader-names.html
$ sudo PCSCLITE_FILTER_IGNORE_READER_NAMES=Cherry pcscd
$ ykls
Reader:  Yubico YubiKey OTP+FIDO+CCID 00 00
Version: 5.1.2
Serial:  9718408

A correct fix would be to ignore a PC/SC reader that do not contain a Yubikey and continue with the next reader in the list.
I guess the problem is this line https://github.com/go-piv/go-ykpiv/blob/master/cmd/ykls/ykls.go#L44

I was about the report, again, the same bug.
But I see it is a known issue since more than 2 years. And nothing happened.
It looks like it is a dead project :-(

source: gharchive/issue

authors: LudovicRousseau nbraud

repo: go-piv/go-ykpiv


text:
Custom error messages for StructLevel validators?

Package version eg. v8, v9:
v9
Issue, Question or Enhancement:
Let's assume I'm validating a struct and there is a string field template which should compile successfully as a valid text/template. If it doesn't compile, I want to know the underlying syntax error.
The problem is that, when I'm validating a field using validator.FieldLevel, there is only an option to return bool and no way to return additional string with an error message itself. Is there a way to workaround this?
When I'm validating a struct using validator.StructLevel, at least there is a way to report custom error messages via sl.ReportError.
Code sample, to showcase or reproduce:
// checks if a given string is valid template
func validateTemplate(fl validator.FieldLevel) bool {
	_, err := template.NewTemplate(fl.Field().String())
	return err == nil
}

result := validator.New()
_ = result.RegisterValidation("template", validateTemplate)

We are already using translations and they are not going to help in this case.
If you look at the code snippet, field level validators only return true/false. But there is no way to return a custom error. I.e. if I get an err from template.NewTemplate(fl.Field().String()), I can only check whether it's nil or not. There is no way for me to return the string of that err to an end user.
We we really want to achieve is to not just return Template is invalid, but return Template is invalid (<underlying error message>)
With struct-level validators it's possible to do sl.ReportError. Not with field-level validators though.

@ralekseenkov I see what you mean now, yes currently there is no way to do this; but it would be a great enhancement!
I will add it to the improvements for v10

ok, thanks!
if you want to take a look at how we are using the library:

https://github.com/Aptomi/aptomi/blob/master/pkg/lang/validation.go
https://github.com/Aptomi/aptomi/blob/master/pkg/lang/contract.go (one of the structs we are validating)

@deankarn hello, it seem that v10 does not support this way yet?

I havnt been able to use RegisterValidationCtx with Gin to get error on custom function validators but it works with RegisterStructValidation, throwing the custom error in sl.ReportError and fetching it back up after casting it back up with validator.ValidationErrors and returning/printing it out with casted[0].Param() as demonstrated here https://github.com/go-playground/validator/blob/f1939ee4461159b2d328c77117eddf66340c0e17/_examples/struct-level/main.go

authors: joeybloggs lacroi-m-insta rainingmaster ralekseenkov

repo: go-playground/validator


text:
cublas can run now but max token size is greatly reduced.

can run but i cant seem to generate the same amount of context size tokens as without using golang. why?
with 4060 rtx, i can do 1920 max tokens using pure llama.cpp cuda offload 100%
on go-llama, i can only do around ctx size of 650 without oom
@mudler do u know why? how do i fix this?
same setting with llama.cpp but in golang...
        var model string

        flags := flag.NewFlagSet(os.Args[0], flag.ExitOnError)
        flags.StringVar(&model, "m", "./models/7B/ggml-model-q4_0.bin", "path to q4_0.bin model file to load")
        flags.IntVar(&gpulayers, "ngl", 0, "Number of GPU layers to use")
        flags.IntVar(&threads, "t", runtime.NumCPU(), "number of threads to use during computation")
        flags.IntVar(&tokens, "n", 1900, "number of tokens to predict")
        flags.IntVar(&seed, "s", -1, "predict RNG seed, -1 for random seed")

        err := flags.Parse(os.Args[1:])
        if err != nil {
                fmt.Printf("Parsing program arguments failed: %s", err)
                os.Exit(1)
        }
        l, err := llama.New(model, llama.EnableF16Memory, llama.SetContext(655), llama.EnableEmbeddings, llama.SetGPULayers(gpulayers))
        if err != nil {
                fmt.Println("Loading the model failed:", err.Error())
                os.Exit(1)
        }
        fmt.Printf("Model loaded successfully.\n")

        reader := bufio.NewReader(os.Stdin)

        for {
                text := readMultiLineInput(reader)

                _, err := l.Predict(text, llama.Debug, llama.SetTokenCallback(func(token string) bool {
                        fmt.Print(token)
                        return true
                }), llama.SetTokens(tokens), llama.SetTemperature(0.3), llama.SetMirostat(2), llama.SetThreads(threads), llama.SetTopK(90), llama.SetTopP(0.86), llama.SetSeed(seed))
                if err != nil {
                        panic(err)
                }
                embeds, err := l.Embeddings(text)
                if err != nil {
                        fmt.Printf("Embeddings: error %s \n", err.Error())

There are many parameters to set - what's the batch size you are using? Is f16 enabled?

authors: hiqsociety mudler


text:
#413 add support for non AWS S3 endpoints

Support for non AWS endpoints, based on this example https://www.digitalocean.com/community/questions/how-to-use-digitalocean-spaces-with-the-aws-s3-sdks?answer=39593
This is the first time I've written in Go, so please let me know if I made a mistake

Pull Request Test Coverage Report for Build 1090

0 of 12 (0.0%)  changed or added relevant lines in 1 file are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.04%) to 42.892%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

cache/s3/s3.go
0
12
0.0%

Files with Coverage Reduction
New Missed Lines
%

provider/gpkg/binary_header.go
2
100.0%

Totals

Change from base Build 1081:
-0.04%

Covered Lines:
4607

Relevant Lines:
10741

💛  - Coveralls

Pull Request Test Coverage Report for Build 1090

0 of 12 (0.0%)  changed or added relevant lines in 1 file are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.04%) to 42.892%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

cache/s3/s3.go
0
12
0.0%

Files with Coverage Reduction
New Missed Lines
%

provider/gpkg/binary_header.go
2
100.0%

Totals

Change from base Build 1081:
-0.04%

Covered Lines:
4607

Relevant Lines:
10741

💛  - Coveralls

I'm about to jump on to a plane, but will look at this later today. Have you tested against both aws and digital ocean? Did it work?

ah didn't test it with aws I'll test it tomorrow and let you know

I just checked and if you do not set an endpoint it works with S3 and if you do set (the correct) endpoint it works with digital ocean :)
However for some reason the tiles are set to private on digital ocean. Which isn't a problem for tegola, since it has a key, but it is for us since we like to serve straight from the blobstore

Ah that is also easily remedied, but would require some thought on your side; tegola needs to set the ACL for the tiles and the aws-sdk supports it if you do this:
	input := s3.PutObjectInput{
		Body:   aws.ReadSeekCloser(bytes.NewReader(val)),
		Bucket: aws.String(s3c.Bucket),
		Key:    aws.String(k),
		ACL:	aws.String("public-read"),
	}

the files are set to public. However I can imagine you want to make this optional or even fully configurable. If you state your preference I can add it to the code if you like. I've created a new issue to track this #415

I've added the necessary settings for ACL to this PR

Do you need anything else for this PR to be accepted?

@stvno Hey sorry, I've had a super busy week last week; I'll try and take a look at it tomorrow.

These changes look good to me less the updates to the package's README. I will accept and then update the readme. Thanks for the contribution!

authors: ARolek coveralls gdey stvno

repo: go-spatial/tegola


text:
add ToRGBA() function support

Please provide Issues links to:

Issues: #

Provide test code:

Description
...

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant vcaesar

repo: go-vgo/robotgo


text:
new backend classes and support for gen 2 cloudfunctions

@anovis

Codecov Report

Merging #198 (aa85ebd) into main (8c38e13) will decrease coverage by 0.90%.
The diff coverage is 87.69%.

@@            Coverage Diff             @@
##             main     #198      +/-   ##
==========================================
- Coverage   89.23%   88.32%   -0.91%
==========================================
  Files          30       35       +5
  Lines        2554     2819     +265
==========================================
+ Hits         2279     2490     +211
- Misses        275      329      +54

Impacted Files
Coverage Δ

goblet/resources/pubsub.py
87.38% <66.66%> (-4.85%)
:arrow_down:

goblet/resources/scheduler.py
82.10% <66.66%> (-2.52%)
:arrow_down:

goblet/common_cloud_actions.py
55.84% <68.29%> (-0.46%)
:arrow_down:

goblet/resources/storage.py
89.09% <72.22%> (-8.83%)
:arrow_down:

goblet/decorators.py
83.52% <76.00%> (-3.19%)
:arrow_down:

goblet/backends/cloudrun.py
84.00% <84.00%> (ø)

goblet/backends/backend.py
85.54% <85.54%> (ø)

goblet/revision.py
88.23% <88.23%> (ø)

goblet/backends/cloudfunctionv2.py
96.15% <96.15%> (ø)

goblet/app.py
83.82% <96.29%> (+7.07%)
:arrow_up:

... and 15 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

authors: codecov-commenter samdevo

repo: goblet/goblet


text:
Added expose 9050, 9060 on Dockerfile

Hi, I have added expose ports in Dockerfile. Because dktest (https://github.com/dhui/dktest) can't find this ports by default. I would be grateful if you accept this PR and rebuild Docker image.

Thank you for your contribution.
The default ports for bigquery-emulator are indeed 9050,9060, but they are not fixed. It can be started on any port by the user. So I don't think it's appropriate to explicitly put the port number in the Dockerfile.

authors: goccy mbobrovskyi

repo: goccy/bigquery-emulator


text:
Integrate with gdrust macro for easy property and signal exports

I wrote gdrust not thinking it would fit in well here, but it turns out it would. This ticket is for discussing how gdrust fits into this project.
Properties
Properties in gdrust use a very gdscript-like syntax:
#[gdrust(extends = Node)]
#[derive(Debug)]
struct HelloWorld {
    #[export_range(0.0, 10.0)]
    simple_range: f32,

    #[export_range(0, 10, 10, "or_greater")]
    #[default(10)]
    simple_range_step_or_greater: u64,

    #[export_enum("This", "will", "be", "enum", "ordinals")]
    int_enum: u32,

    #[export_file("*.png")]
    png_file: String,
}

In general, I think we should try to keep this syntax as it maps well to Godot's syntax. I discussed some syntax ideas with @toasteater  on discord, and there are a few things we should keep in mind:

This should ideally be merged with #[property]
We should try to retain some functionality of #[property], namely the path and accessor hooks:

#[property(path = "foo/bar", after_set = "Self::_update_stuff")]
foo_bar: i32

One difference between gdrust and the #[property] syntax is the way other information such as default and getters and setters are defined. #[property] favors grouping them all in one attribute like the example above, whereas gdrust tries to split them into multiple attributes. The reason gdrust splits them is that godot's export documentation defines an "annotation-style" syntax. Export hint information is added as annotation arguments. default and getters/setters were placed in separate attributes to prevent interfering with godot's syntax. As a result, there are more lines of code, but it is easier to read and we aren't cramming everything in one big attribute. We don't have to bring this to gdnative-rust, but it is worth considering.
Things to consider

Should fields be exported by default? Probably not.
Should we put all the property information in one attribute, or split it out into many (export_*, default, path, setter, getter, etc.)?
Will this replace property, or is there still a need for property?
Should "or_greater" and "or_lesser" not be strings? Parsing a list of Lits is easy, but there's no reason they couldn't be keywords: #[export_range(0, 10, 10, or_lesser, or_greater)].

Signals
Signals in gdrust are defined with an attribute on a struct:
#[gdrust(extends = Node)]
#[signal(my_signal(arg1: F64, arg2: GodotString = "test".to_string()))]
#[signal(simple_signal(arg:I64))]
#[derive(Debug)]
struct HelloWorld;

The syntax was chosen to look like gdscript. You may be wondering why the types are weird; they are required to be (VariantTypes)[https://docs.rs/gdnative/0.9.3/gdnative/core_types/enum.VariantType.html]. I suppose this is not a hard requirement, but it makes it much easier to export the signal as it requires a VariantType instead of a generic.
Things to consider

Should we change the VariantType to a rust type?
Is the syntax good?
gdrust exports a const with the signal name. This is good for ensuring anyone emitting on the signal is emitting with the correct name at compile time, but it is a bit of magic.
Is there a better place for this attribute than on the struct? It works, and seems to be the best place, but there may be a better option.

unsafe_functions
A collection of extension functions that make coding easier at the risk of crashing the program. I wasn't asked to include this, but I'm throwing it in for clarity. It sounds like the unsafe nature of these functions means they should not be a part of this library and should maybe live in gdrust. Let me know if there are other opinions.

Regarding unsafe_functions: we now have a module gdnative::api::utils for helper functions that depend on generated bindings, but yes they do need to be correctly marked as unsafe if necessary. We already have something similar like NodeExt::get_node_as, albeit correctly unsafe and without the final expect.

+1. Need this!

authors: phenax toasteater wyattjsmith1

repo: godot-rust/godot-rust


text:
intersect_ray() ignores any TileMap cells with collision polygons after a call to TileMap.set_cell()

Godot version: 3.2
OS/device including version: Manjaro Linux 18.1.5
Issue description: If you change a cell (on a TileMap) from a tile with collision polygon to a tile without collision polygon, the next call to Physics2DDirectSpaceState.intersect_ray() will not collide with any TileMap cells. This only happens if a call to intersect_ray() is made during next _physics_process tick right after set_cell() call had happened on a _process() tick.

I believe it is a regression, since this does not happen on version 3.1.2.
Steps to reproduce:

During _process() tick, call TileMap.set_cell() and change a cell from a tile with collision polygon to a tile without.
On the next _physics_process() tick, call Physics2DDirectSpaceState.intersect_ray() directed at a TileMap cell with a collision polygon.

Minimal reproduction project:
ReproductionProject.zip

Hey, I think I have got same error happening. Is there an update on this? or a workaround?

@Crare, I'm doing TileMap operations on physics tick as a workaround:
`func destroy_tile(world_pos: Vector2, destroy_all: bool = false) -> bool:
var tile_idx := world_to_map(world_pos)
if not destroy_all and get_cell(int(tile_idx.x), int(tile_idx.y)) == TILE_WALL_INDESTRUCTIBLE:
return false
## Workaround Godot issue #35725
#set_cell(int(tile_idx.x), int(tile_idx.y), TILE_FLOOR)
_destroy_tile_queue.append(tile_idx)
return true
Workaround Godot issue #35725
func _physics_process(delta: float) -> void:
if not _destroy_tile_queue.empty():
for tile_idx in _destroy_tile_queue:
set_cell(int(tile_idx.x), int(tile_idx.y), TILE_FLOOR)
_destroy_tile_queue.clear()
`
I think you may also try calling TileMap.update_dirty_quadrants ( ) after attempted changes.

I bisected the regression, it's caused by #29951. CC @raphael10241024 @pouleyKetchoupp
commit 434fd71d2a4b69f576362c3a9baa5b39db009d31
Author: yakun.zhang <Raphael10241024@gmail.com>
Date:   Fri Jun 21 19:33:01 2019 +0800

    add 2d physic optimization simlilar to 3d physics

Now, regardless of this issue, if you update the tilemap and expect to do physics-based tests after this, you should do your tilemap update logic in _physics_process. Even there, you should be aware that any changes done to physics (like adding/removing colliders as done here) will only take effect in the next iteration - but it's wrong here that the whole collision shape becomes inactive instead of keeping its pre-removal state.

I bisected the regression, it's caused by #29951. CC @raphael10241024 @pouleyKetchoupp
commit 434fd71d2a4b69f576362c3a9baa5b39db009d31
Author: yakun.zhang <Raphael10241024@gmail.com>
Date:   Fri Jun 21 19:33:01 2019 +0800

    add 2d physic optimization simlilar to 3d physics

Now, regardless of this issue, if you update the tilemap and expect to do physics-based tests after this, you should do your tilemap update logic in _physics_process. Even there, you should be aware that any changes done to physics (like adding/removing colliders as done here) will only take effect in the next iteration - but it's wrong here that the whole collision shape becomes inactive instead of keeping its pre-removal state.

authors: Caenhorn Crare akien-mga

repo: godotengine/godot


text:
Freeing TabContainer with direct child of type AnimationPlayer produces Error

Godot version: 3.2 Stable
OS/device including version: Win 10
Issue description:
Freeing TabContainer with direct child of type AnimationPlayer produces following Error
_disconnect: Nonexistent signal 'renamed' in [AnimationPlayer:3588].
<C++ Error>   Condition "!s" is true.
<C++ Source>  core/object.cpp:1518 @ _disconnect()
If AnimationPlayer is a grandchild of TabContainer, error does not come up.
Steps to reproduce:
Run Attached Project, main scene has two instanced child scenes, one with direct child AnimationPlayer which produces error on queue_free, and one with AnimationPlayer as grandchild ( a Control inbetween ) which produces no error on queue_free.
Minimal reproduction project:
animationplayerbug.zip

Can reproduce error in 3.2.2.stable on linux mint 18.3.
However, is your minimal reproduction project set up as you intended?

As I said it still produces the error, but the grandchilded AnimationPlayer seemed an important detail in your description.

The error should not occur if the animation player is a grandchild of the tabbed container but with a control parent.

Still happens with 3.2.4.beta.custom_build. 2d904127d
ERROR: _disconnect: Attempt to disconnect a nonexistent connection to signal 'renamed' in [AcceptDialog:2723], with target '_child_renamed_callback' in [TabContainer:2786].
   At: core/object.cpp:1569.

Automatic minimal project
RegressionTestProject.zip

Still happens with 3.2.4.beta.custom_build. 2d904127d
ERROR: _disconnect: Attempt to disconnect a nonexistent connection to signal 'renamed' in [AcceptDialog:2723], with target '_child_renamed_callback' in [TabContainer:2786].
   At: core/object.cpp:1569.

Automatic minimal project
RegressionTestProject.zip

Happens on any control as well if you set it to drag_to_rearrange_enabled and drag a tab. Seems like any time you remove a node will force disconnect rename signal even if it hasn't been set.

authors: filipworksdev jeanlucami qarmin tom-jk


text:
Can't disable custom android plugin

Godot version:
3.2.2 beta3
OS/device including version:
Windows 10
Issue description:
I sucessfully created an Android plugin using the new v1 system and deployed it on a phone. I then disabled it in the export settings, built again and got this gradle error:

The only way to fix this is to either:

Enable the plugin again
Clear/delete the build folder and rebuild

Note that i never enabled the GodotPayment plugin.
Steps to reproduce:

Enable custom Android template build
Add a barebones custom plugin to plugins folder
Enable it in export settings and build -> builds fine
Disable it in export settings and build -> build error

Looking into it. We may need to automatically delete the res://android/build/build directory when we detect a dependency is newer than it.

@m4gr3d @akien-mga I have a PR ready, that would fix this but i only tested it on the 3.2 branch since   i'm not sure if android builds are currently possible on master? Since this is easily cherry-pickable i'm just going to open this against master for now.


text:
Search in script should scroll line to the center

Tested on Godot 2.0.3, Windows 10 64 bits:
When I search something in a script, the editor scrolls down to that line, but I cannot see what's next. This is not convenient because I loose half of the context.
It would be better to scroll the line to the center of the view, like any other editor does (Sublime; Npp++, VS...).

Could be referred in https://github.com/godotengine/godot/issues/2982

The find/replace dialog was replaced by a bar in the current master branch, but the above behaviour is still valid. I'll have a look.

authors: Zylann neikeq


text:
property_changed signal on EditorProperty has wrong signature in documentation.

Godot version
3.5.mono.stable
System information
Windows 10
Issue description
Source code emits four arguments (String, Variant, String, boolean)
https://github.com/godotengine/godot/blob/b0ab7ac446100d490a5ce14c538e2bc88ade65cf/editor/editor_inspector.cpp#L106-L111
Documentation says only two arguments
https://docs.godotengine.org/en/stable/classes/class_editorproperty.html

Steps to reproduce
See above.
Minimal reproduction project
No response

This also occurs on the master branch
https://github.com/godotengine/godot/blob/051f24b067642a241d0a4acbb1b7644e11700bfc/editor/editor_inspector.cpp#L114-L120
https://github.com/godotengine/godot/blob/051f24b067642a241d0a4acbb1b7644e11700bfc/doc/classes/EditorProperty.xml#L105-L111


text:
RayCast debug shape culled by Rooms and Portals (when Visible Collision Shapes is enabled)

Godot version
v3.5.stable.official [991bb6ac7]
System information
Windows 10, GLES3
Issue description
Room conversion culls RayCast's debug shape.
Possible solutions:

Access CullInstance from the inspector
Default to PORTAL_MODE_GLOBAL

Steps to reproduce

Enable Visible Collision Shapes.
Add RayCast in 3D environment and camera to render it.
Set up Rooms and Portals in the same environment.
Run the scene.

extends Spatial

func _ready():
	pass
	$RoomManager.rooms_convert()

Minimal reproduction project
RayCast Bug.zip

cc @lawnjelly

I can switch this to work, but in general, a lot of debugging stuff will not show up when portals are active. I tried to mention this in the docs, I found this for RoomManager::active, and I'm sure I mentioned it elsewhere:

It is important to note that when portal culling is active, it is responsible for all the 3d culling. Some editor functionality may be more difficult to use, so switching the active flag is intended to be used to make sure your Room / Portal layout works within the editor.

Also see here:
https://docs.godotengine.org/en/stable/tutorials/3d/portals/first_steps_with_rooms_and_portals.html#room-conversion

If you convert the level while the editor is running, the portal culling system will take over from the normal Godot frustum culling, potentially interfering with editor features.

There is likely quite a bit of debugging stuff that does not show up, during debugging you are recommended to not activate portals. Once you are finished debugging, then reactivate. It is not really a bug, more a design consequence. I can individually switch these elements to show but it adds more code for not great reasons.
Of course there might be a situation where you want to use the debugging objects to debug your portal setup, in which case I do sympathize. :grin:
Incidentally the reason for this is that editor debuggers (and debuggers you can switch to show during runtime) are not regular VisualInstances. They often create RIDs through the VisualServer directly, and need to have a portal mode set for the system to understand them and decide whether or not to show them.

Fixed by #65684 and #65686.

authors: Calinou Sirus97 akien-mga lawnjelly


text:
TileMap causes it to run slower

Godot version
4.0beta1
System information
windows10
Issue description

In the same case, 3.5 loaded for 3 seconds and 4.0 loaded for 1 minute
Steps to reproduce

In the same case, 3.5 loaded for 3 seconds and 4.0 loaded for 1 minute
Minimal reproduction project
No response

@xiaoliang6669 Please upload a minimal reproduction project to make this easier to troubleshoot.
The reason for this occurring is likely that TileMap images were saved as serialized Base64 within the .tres file instead of external PNG images.

You're right, but I usually merge images with TexturePacker, a third-party software, to reduce the size of images

This seems expected. You are not supposed to have that many atlases in you TileSet and should use the atlas merging tool to reduce the number of atlas sources. The atlas merging tool is accessible from the menu with 3 dots at the bottom.

@groud
A tile 320*240, a total of 840 pieces make up a complete large map, I need to dynamically load and unload each tile in the script to achieve the correct display of the map. There is also a problem, how to use the script implementation to set the navigation shape for each tile, 3.0 I implemented, but 4.0 everything changed.

A tile 320*240, a total of 840 pieces make up a complete large map, I need to dynamically load and unload each tile in the script to achieve the correct display of the map.

How many tile you have is not a problem, you need to move them all to a single tile atlas, not use one atlas per tile, which is really inefficient.

There is also a problem, how to use the script implementation to set the navigation shape for each tile, 3.0 I implemented, but 4.0 everything changed.

This is implemented in 4.0 too but needs to be documented I suppose.

authors: Calinou groud xiaoliang6669


text:
High pitched static noise without playing any audio

Godot version
4.0 beta 3
System information
Windows 11, Vulkan, RTX 3070
Issue description
High pitched Static Noise in almost empty scene without any audio related node in 3D
Pitch changes based on camera rotation and MeshInstance Material the camera is looking at.
Im not talking about the normal speaker noise but the high pitched in between. Whenever I am tilting the camera towards the floor the pitch changes to the louder one and when looking back it becomes higher but more quiet.
https://user-images.githubusercontent.com/47256718/196002659-a784dfb1-1681-422f-afd6-161fe1e7e08a.mp4
Happens on EVERY speaker/headphone I try.
ONLY happens in this specific project.
Across ALL betas and alphas. (8-13)
CAN NOT reproduce thus the attached Project.
Steps to reproduce
No idea.
Minimal reproduction project
AudioBug.zip

Have you confirmed that the sound is coming out of your speakers and is not coming from your CPU/CPU fan?
If the sound is coming from the computer (not through the speakers) the issue may be a result of the computer overworking itself from not having vsync on. In an empty or near empty scene without vsync, Godot will render as many frames per second as your computer can handle. This can lead to a high CPU/GPU load which stresses your system.

Indeed without vsync the issue no longer exists however the noise 100%
comes from the speakers and not the computer itself. (I asked my family as
well and only the person with headphones on could hear the noise)
Clay John @.***> schrieb am Sa., 15. Okt. 2022, 20:58:

Have you confirmed that the sound is coming out of your speakers and is
not coming from your CPU/CPU fan?
If the sound is coming from the computer (not through the speakers) the
issue may be a result of the computer overworking itself from not having
vsync on. In an empty or near empty scene without vsync, Godot will render
as many frames per second as your computer can handle. This can lead to a
high CPU/GPU load which stresses your system.
—
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/67457#issuecomment-1279809174,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALIRJDUS6L5OPNJYPXIMBB3WDL5DPANCNFSM6AAAAAARGAQ2JM
.
You are receiving this because you authored the thread.Message ID:
@.***>

From the description it sounds like coil whine (typically high pitch hard to hear) or electric interference on a badly isolated motherboard (which ends up on the audio port and travels up into your headset).
Can you confirm the sounds till occurs when you have Godot muted in your OSs audio mixer? Can you confirm that a desktop recording contains the sound?

I've tested unity and unrealy and minecraft an none of those had any noise at all (at uncapped framerate with maxed out GPU and CPU).
I dug a bit into coil whine and it appears it can change from application to application. Still odd it only happens in 4.x
(The same project has no noise AT all in 3.x + 3.x runs the same project at roughly double the fps)

I've tested unity and unrealy and minecraft an none of those had any noise at all (at uncapped framerate with maxed out GPU and CPU).

This basically means nothing when it comes to coil whine. Yep.

Edit : the noise persists with muted Godot (both editor and debug scene).

Last test you can do is to complete mute all system sound. But it sounds like it boils down to a cosmetic hardware error.

@RevoluPowered found some causes of audio error for the mac

It seems fixed in the master branch.
It's still noticeable in beta 3 but isn't in master. I can't tell when it vanished since I didn't really try the betas but its gone now 🤷. (Used the same project AND new ones.)
I'll comment again if it returns..

Thanks, closing for now then.

For future readers,
Coil whine happens when FPS is outrageously high in any project.
Set a FPS limit to cap FPS, 300FPS seems like a reasonable amount, and works for me.
Setting can be found in application >run > max_fps

authors: CoreTaxxe Stalker2106x TheDuriel akien-mga clayjohn fire


text:
queue_free() in animation breaks ray-tracing if run in editor

Godot version
3.5.1
System information
Fedora
Issue description
Perhaps this is expected behavior, I'm new to this.  But I tried running an enemy animation in a demo project which calls queue_free() at the end, and -- once I do that a single time -- all of the enemies RayTracers stop interacting.
It seems like running an animation shouldn't substantially affect the project.
Steps to reproduce

Open the "Platformer 2D (Raytrace)" Demo project
Go to the enemy entity
Run the "destroy" animation
Everything is borked in game now

Minimal reproduction project
N/A

This is the animation.  And it turns out it doesn't break the ray tracing, but instead it's collision stuff?  It's really weird and hard to explain as this is my first day.

Call method tracks in the editor are supposted to be ineffective.

Oh, yeah.  Thanks.  I'm really having a hard time figuring this out.  If I close the project and reopen, it's still broken.  If I close godot and reopen, it's still broken.  The only thing I can do to get it working again is delete the entire project and re-download it.

Oooh!  It might be that it changes the collision layer.  But still, why would playing an animation change anything about what goes on inside the game?

Oooh! It might be that it changes the collision layer. But still, why would playing an animation change anything about what goes on inside the game?

This is likely an issue with the demo itself. The AnimationPlayer lacks a suitable RESET track with tracks for all properties that need to be reset when opening the scene in the editor. This is common in projects made before Godot 3.4 and ported over.

Thanks, I just found the answer here too: https://github.com/godotengine/godot-proposals/issues/3829
It's an older project, as you said.

authors: Calinou SephReed


text:
4.0.rc1: VisualShader Expression Node window height reset after reload

Godot version
4.0.rc1
System information
Windows 10
Issue description
The height of the Expression node windows is reseted after reload:

Steps to reproduce

Create a Visual shader with an Expression node
adjust the Expression node window height
save and reload the godot project

Minimal reproduction project

seam to be fixed in Godot 4.0 rc2

seams to be fixed in Godot 4.0 rc2


text:
Error when assigning unnamed GDScript with exported variables

Godot version
master
System information
W11
Issue description
This issue only happens in master, it does not occur in 4.0.2 so it is a recent regression.
When assigning a script without a class_name and with at least one @export variable to a node in the scene tree (and every time you save the script after), you will get an error: Class name cannot be empty.
The error appears to originate from the first line of Ref<Texture2D> EditorNode::get_class_icon(const String &p_class, const String &p_fallback):
ERR_FAIL_COND_V_MSG(p_class.is_empty(), nullptr, "Class name cannot be empty.");
Steps to reproduce
Create a script with
extends Node

@export var x : int

Then assign it to a node in your scene. The error will occur. Remove the @export and it will no longer occur. Add it again, and it will, every time you save the file.
Minimal reproduction project
N/A

I guess it's a regression from https://github.com/godotengine/godot/pull/75472.

I guess it's a regression from #75472.

That sounds right, from the stack trace I was looking at it seemed to specifically be related to _extension being null, so hopefully a simple check ought to fix it?

So the error is in line 2779:
https://github.com/godotengine/godot/blob/master/editor/editor_inspector.cpp#L2761-L2782
script_name is empty because script_name = EditorNode::get_editor_data().script_class_get_name(scr->get_path()); returns empty since the path doesn't lead to a name. I guess here we want to default to something like GDScript or something?
I don't know enough about this part to be helpful :)

I'm working on a fix for one :)

Here you get the same error even if you assign a value:
extends Node
@export var y := 1 :
	set(v):
		pass

Deselect / select the Node with the attached script:
ERROR: Class name cannot be empty.
at: get_class_icon (editor/editor_node.cpp:4471)
...

authors: YuriSizov anvilfolk capnm


text:
Area2D panics when added to scene tree in colliding position

Operating system or device - Godot version:
Godot v2.1.2 Stable.
Issue description:

TL;DR version: Basically the following is spamming the debugger output. Although collisions are working fine.
File: area_2d.cpp , line: 165
ERR_FAIL_COND(!body_in && !E);

Detailed verison: my issue is that I am trying to implement a node that changes its children after a set of time (like toggle between two states every 5 seconds). When I do add_child to the node that contains Area2D, and at the same time, let's say the player was in the location where the object is about to toggle its state by adding child node, the error happens (using add_child). The Area2D has body_enter signal.
Have a look here in the forum's post about this issue. I was kind of happy when I thought the issue is fixed, when I changed the overlapping collision shapes of the node containing Area2D (the parent node has a KinematicBody2D too). But soon I realized the issue appears again when dealing with other nodes (like the one toggles its state) at the same location.
Things I tried,

call_deferred for adding or removing the node that contains the Area2D didn't work.
disconnect before removing Area2D's parent (using remove_child) and connect again before add_child

My only option which I don't like to go there, is to make Area2D permanent and never removed or added (by putting it in a different parent), and switch or toggle states using code. That would be ugly.
Like I said, collisions are working fine, even when add_child for the Area2D (maybe the collisions are reported in the next frame, which I don't care as long as they are reported). Only the debugger output spamming. I wish to know if there is a cleaner approach.
Any suggestions!
Issues similar to this:
Issue #3589 (closed)
Link to minimal example project:
:

Try removing all the masks and layers first, as workaround, I remember that had to do that in one specific case where I was toggling the monitoring on Area2D.

@eon-s Interesting. Thanks for the tip. But that didn't work, but what worked is disabling monitoring before removing child, and enable monitoring after adding child. The issue seems to be gone, even with overlapping collision shapes of the area2d with sibling's (e.g, parent has a KinematicBody2D) collision shape.
Despite there is a workaround for this, it either must be mentioned in the documentation to do so when adding/removing child of type area2d in script, or fixed. As it is right now, it is unexpected behavior.

@lonesurvivor That is exactly what happened to me. I have experienced all these issues and error messages while trying different stuff to fix it. How did I miss your issue and your PR while searching the issue tracker, I don't know.
It seems you did what I did, just behind the scenes ;) that is, storing the state of monitoring, disable it before exiting scene tree and restore it upon re-entering the scene tree.
I hope your PR gets merged soon for the 2.1 branch. Although it is reassuring it is not needed for 3.0, but I am not sure if I will export my project to 3.0 when it gets released.

@lonesurvivor I didn't try your changes, but I tried to disconnect before remove_child and connect after add_child manually in script, that didn't help. So what made you remove the storing and restoring of monitoring state

@RebelliousX
I removed that because it worked without it in 3.0. I left the rest of the PR (the disconnects) since I'm pretty sure it is wrong as it is now although it doesn't cause any error messages in 3.0 either.
I guess I should just make a new PR for the 2.1 branch tomorrow (after fixing the whitespaces). At the time I made this fix, I didn't think that 2.1 would still be a thing for such a long time, so I kept it for myself...

@lonesurvivor much obliged 👍 Thanks again.

No problem. Done.

@lonesurvivor Thanks again.

authors: RebelliousX eon-s lonesurvivor


text:
Signals trigger in-editor, leads to confusing behavior, crashes

Godot version
v4.1.1.stable.official [bd6af8e0e]
System information
Windows 11
Issue description
So this is a general permutation of several existing bug reports which point to a larger underlying issue. I'm on the fence regarding if this is an issue or a proposal, but given that it's causing editor crashes and multiple bug reports going back several years, I'm going to go out on a limb and suggest that this is undesired behavior that should be treated as its own specific issue, even if its fix may require some manner of executive decision on how to resolve it.
Here's a summation of the issue: In the editor, you can connect signals to methods. If the method is a part of a script, the method will be called iff the script is a tool script. If, however, the method is innate to the node, the method will be called even if there's no script attached at all. This leads to incredibly easy crashes in response to fairly innocuous behavior, such as hooking up queue_free to an animation_finished signal and then trying to play a non-looping animation in the editor.
There are multiple ways to fix this. If I had to suggest one off the top of my head, it'd be to disable firing node signals in the editor entirely unless there's a tool script attached. Alternatively, editor signal connections could be given a toggle to disable or enable triggering within the editor on an individual basis. The specific crashes caused by queue_free in the editor is a wider issue that could be addressed, but given that there are actual uses for calling queue_free within the editor, the actual logic for screening such things could be more trouble than it's worth.
Related bug reports (that I could find - there may be others):
https://github.com/godotengine/godot/issues/73771#issue-1595507044
https://github.com/godotengine/godot/issues/56230#issue-1088518418
https://github.com/godotengine/godot/issues/27125#issue-421817788
Steps to reproduce
There are multiple ways to go about this.
The most trivial is to create a Node2D and tie a method to its visibility_changed or hidden signals. If you're looking for a benign example, print_tree dumps a period in the output. If you're looking for a less benign example, try queue_free.
Minimal reproduction project
signal_crash.zip
I hesitated to even bother creating an MVP for this given that it skirts the fringes between bug and undesired behavior, but I think there's value in demonstrating just how utterly trivial it is to create something which crashes the editor. Although the example is slightly contrived, even a more realistic example (e.g. queue_free on animation_finished) is simple enough that the average user could run into it without knowing why.

Seems to me like it's reasonable to only allow editor connections to script functions.

Seems to me like it's reasonable to only allow editor connections to script functions.

The thing is, there are still very practical cases where you'd want to connect signals to built-in methods. The animation_finished callback isn't a contrived example - it's how I actually ran into this issue in the first place. It's just that signals probably shouldn't be triggered in the editor unless you're explicitly running a tool script.

Duplicate of #67864
#74796 will fix this.

authors: Jordyfel KoBeWi vpellen


text:
Script Editor with long lines in code, does not reopen script in same position as was saved, scrolling it to the right

Tested versions
v4.3.dev5.official [c9c17d6ca]
System information
Linux Kubuntu 23.04 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8
Issue description
When opening up scripts from Filemanager, if the contain long lines and the cursor position is saved someplace in the middle, the script opens up scrolled to the right.
Steps to reproduce
If you have a script with some long lines that go past the viewing area of the editor, and save it, when you reopen it, the script and cursor may be positioned incorrectly such as in screen shot below:

Minimal reproduction project (MRP)
Sample project:
Archive.zip

Duplicate of #33865

authors: KoBeWi wyattbiker


text:
USER ERROR: FATAL: Index p_index = 4294967294 is out of bounds (count = 32772).    at: operator[] (./core/templates/local_vector.h:161)

Tested versions

Reproducable, though I'm sure this is a rare instance lol.
Godot 4.2.2, Forward+

System information
Godot v4.2.2.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated AMD Radeon RX 7900 XT (Advanced Micro Devices, Inc.; 31.0.24002.92) - 13th Gen Intel(R) Core(TM) i5-13600K (20 Threads)
Issue description
I'm creating a minecraft like  game using cubes, See this video : https://www.youtube.com/watch?v=iQS3WelK7pU
And find the source code : https://pastebin.com/dtgJ8na8
I reliably get this error when I up the render_distance to around 18 - 24. The queue does not grow beyond 100, but the game crashes, and the only error supplied is:
USER ERROR: FATAL: Index p_index = 4294967294 is out of bounds (count = 32772).    at: operator[] (./core/templates/local_vector.h:161)
I have no idea whats causing it. Any help is appreciated.
Steps to reproduce
Up the chunks to beyond 18, crashes randomly.
Minimal reproduction project (MRP)
Honestly I'm not sure what causes this. Sorry.

Update :
extends Node3D
The size of each chunk in blocks
var chunkSize = Vector3(16, 16, 16)
var renderDistance = 20
var generatedChunks = {}
var queue = []
var tasksPerFrame = 1
var current_player_chunk = Vector3(-999, 0, -999)  # Invalid initial chunk position
The size of the world in chunks
var initialWorldSize = Vector3(8, 1, 8)  # Adjust based on your needs
Noise generator instance
var noise_generator : FastNoiseLite
MeshLibrary containing block meshes
@export var mesh_library : MeshLibrary
GridMap to manage the voxel terrain
@onready var grid_map : GridMap = $GridMap
func _ready():
# Load the mesh library from the provided file
mesh_library = load("res://Resources/blocks.tres")
# Initialize the noise generator
noise_generator = FastNoiseLite.new()
noise_generator.noise_type = FastNoiseLite.TYPE_SIMPLEX_SMOOTH
noise_generator.seed = randi()
noise_generator.frequency = 0.01  # Controls the frequency of the noise

# Assign the mesh library to the GridMap
grid_map.mesh_library = mesh_library

func _process(delta):
var playerPos = getPlayerPos()
var playerChunk = getPlayerChunk(playerPos)
if playerChunk != current_player_chunk:
	current_player_chunk = playerChunk
	generateChunkAroundPlayer(playerChunk)

processQueue()
generateChunkAroundPlayer(playerChunk)

func generateChunkAroundPlayer(playerChunk: Vector3):
for x in range(-renderDistance, renderDistance + 1):
for z in range(-renderDistance, renderDistance + 1):
var chunkPos = playerChunk + Vector3(x,0,z)
if not generatedChunks.has(chunkPos):
queue.append(chunkPos)
func processQueue():
for i in range(min(queue.size(), tasksPerFrame)):
var chunkPos = queue.pop_front()
generateChunk(chunkPos)
generatedChunks[chunkPos] = true
Function to generate a single chunk of terrain
func generateChunk(playerChunk: Vector3):
for x in range(chunkSize.x):
for z in range(chunkSize.z):
var world_x = int(playerChunk.x * chunkSize.x + x)
var world_z = int(playerChunk.z * chunkSize.z + z)
var height = int(noise_generator.get_noise_2d(world_x * 0.1, world_z * 0.1) * 10) + 10
for y in range(chunkSize.y):
var world_y = int(y)
if world_y <= height:
if noise_generator.get_noise_3d(world_x * 0.1, world_y * 0.1, world_z * 0.1) < 0.5:
set_block(world_x, world_y, world_z, "Grass")
elif world_y < height - 3:
set_block(world_x, world_y, world_z, "Dirt")
else:
set_block(world_x, world_y, world_z, "Stone")
func getPlayerPos():
return get_node("/root/Level/Player").global_transform.origin / 2
func getPlayerChunk(playerPosition):
return Vector3(
int(floor(playerPosition.x / chunkSize.x)),
0,
int(floor(playerPosition.z / chunkSize.z))
)
Function to set a block in the GridMap
func set_block(x: int, y: int, z: int, block_type: String):
var block_id = mesh_library.find_item_by_name(block_type)
if block_id >= 0:
grid_map.set_cell_item(Vector3i(x, y, z), block_id)
This code alone seems to trigger that issue.

extends Node3D
The size of each chunk in blocks
var chunkSize = Vector3(16, 16, 16)
var renderDistance = 20
var generatedChunks = {}
var queue = []
var tasksPerFrame = 1
var current_player_chunk = Vector3(-999, 0, -999)  # Invalid initial chunk position
The size of the world in chunks
var initialWorldSize = Vector3(8, 1, 8)  # Adjust based on your needs
Noise generator instance
var noise_generator : FastNoiseLite
MeshLibrary containing block meshes
@export var mesh_library : MeshLibrary
GridMap to manage the voxel terrain
@onready var grid_map : GridMap = $GridMap
func _ready():
# Load the mesh library from the provided file
mesh_library = load("res://Resources/blocks.tres")
# Initialize the noise generator
noise_generator = FastNoiseLite.new()
noise_generator.noise_type = FastNoiseLite.TYPE_SIMPLEX_SMOOTH
noise_generator.seed = randi()
noise_generator.frequency = 0.01  # Controls the frequency of the noise

# Assign the mesh library to the GridMap
grid_map.mesh_library = mesh_library

func _process(delta):
var playerPos = getPlayerPos()
var playerChunk = getPlayerChunk(playerPos)
if playerChunk != current_player_chunk:
	current_player_chunk = playerChunk
	generateChunkAroundPlayer(playerChunk)

processQueue()
generateChunkAroundPlayer(playerChunk)

func generateChunkAroundPlayer(playerChunk: Vector3):
for x in range(-renderDistance, renderDistance + 1):
for z in range(-renderDistance, renderDistance + 1):
var chunkPos = playerChunk + Vector3(x,0,z)
if not generatedChunks.has(chunkPos):
queue.append(chunkPos)
func processQueue():
for i in range(min(queue.size(), tasksPerFrame)):
var chunkPos = queue.pop_front()
generateChunk(chunkPos)
generatedChunks[chunkPos] = true
Function to generate a single chunk of terrain
func generateChunk(playerChunk: Vector3):
for x in range(chunkSize.x):
for z in range(chunkSize.z):
var world_x = int(playerChunk.x * chunkSize.x + x)
var world_z = int(playerChunk.z * chunkSize.z + z)
var height = int(noise_generator.get_noise_2d(world_x * 0.1, world_z * 0.1) * 10) + 10
for y in range(chunkSize.y):
var world_y = int(y)
if world_y <= height:
if noise_generator.get_noise_3d(world_x * 0.1, world_y * 0.1, world_z * 0.1) < 0.5:
set_block(world_x, world_y, world_z, "Grass")
elif world_y < height - 3:
set_block(world_x, world_y, world_z, "Dirt")
else:
set_block(world_x, world_y, world_z, "Stone")
func getPlayerPos():
return get_node("/root/Level/Player").global_transform.origin / 2
func getPlayerChunk(playerPosition):
return Vector3(
int(floor(playerPosition.x / chunkSize.x)),
0,
int(floor(playerPosition.z / chunkSize.z))
)
Function to set a block in the GridMap
func set_block(x: int, y: int, z: int, block_type: String):
var block_id = mesh_library.find_item_by_name(block_type)
if block_id >= 0:
grid_map.set_cell_item(Vector3i(x, y, z), block_id)
This code seems to trigger it just by itself

Your code can't run because don't have the assets that you use and also don't have the scene tree with the correct nodes, will make debug much more easier if you upload a MRP with everything ready to test

@matheusmdx  Thanks for the reply, I've uploaded the version to github, theres pretty much nothing else there so it's pretty much an MRP. Perhaps you could give it a run? The issue happens when I up the render_distance in level.gd from 12 to like.... 21ish?

I'm unable to look at the project currently, but notice that set_block isn't bounds checked and world_x and world_z could be less than zero (-1 == (uint32)4294967294)
func set_block(x: int, y: int, z: int, block_type: String):
	assert(x >= 0 and y >= 0 and z >= 0, "oh no")

@huwpascoe Thanks for the reply. Correct my if im wrong (beacuse I probably am), but would this not just disallow generation of blocks with a negative coordinate, as this should be possible. Also just realised the code snippet I sent wasnt the full one. The full one is in the repo, Scripts/level.gd. Thanks

I tested the code and was able to get a backtrace:
LocalVector<BVH_Tree<GodotCollisionObject3D,2,2,128,GodotBroadPhase3DBVH::UserPairTestFunction<GodotCollisionObject3D>,GodotBroadPhase3DBVH::UserCullTestFunction<GodotCollisionObject3D>,1,AABB,Vector3>::TLeaf,unsigned int,1,0>::operator[](unsigned int p_index) Line 177 (c:\Users\Matheus\Downloads\Godot Source\core\templates\local_vector.h:177)
PooledList<BVH_Tree<GodotCollisionObject3D,2,2,128,GodotBroadPhase3DBVH::UserPairTestFunction<GodotCollisionObject3D>,GodotBroadPhase3DBVH::UserCullTestFunction<GodotCollisionObject3D>,1,AABB,Vector3>::TLeaf,unsigned int,1,0>::operator[](unsigned int p_index) Line 90 (c:\Users\Matheus\Downloads\Godot Source\core\templates\pooled_list.h:90)
BVH_Tree<GodotCollisionObject3D,2,2,128,GodotBroadPhase3DBVH::UserPairTestFunction<GodotCollisionObject3D>,GodotBroadPhase3DBVH::UserCullTestFunction<GodotCollisionObject3D>,1,AABB,Vector3>::_node_get_leaf(BVH_Tree<GodotCollisionObject3D,2,2,128,GodotBroadPhase3DBVH::UserPairTestFunction<GodotCollisionObject3D>,GodotBroadPhase3DBVH::UserCullTestFunction<GodotCollisionObject3D>,1,AABB,Vector3>::TNode & tnode) Line 44 (c:\Users\Matheus\Downloads\Godot Source\core\math\bvh_misc.inc:44)
BVH_Tree<GodotCollisionObject3D,2,2,128,GodotBroadPhase3DBVH::UserPairTestFunction<GodotCollisionObject3D>,GodotBroadPhase3DBVH::UserCullTestFunction<GodotCollisionObject3D>,1,AABB,Vector3>::_node_add_item(unsigned int p_node_id, unsigned int p_ref_id, const BVH_ABB<AABB,Vector3> & p_aabb) Line 399 (c:\Users\Matheus\Downloads\Godot Source\core\math\bvh_tree.h:399)
BVH_Tree<GodotCollisionObject3D,2,2,128,GodotBroadPhase3DBVH::UserPairTestFunction<GodotCollisionObject3D>,GodotBroadPhase3DBVH::UserCullTestFunction<GodotCollisionObject3D>,1,AABB,Vector3>::split_leaf_complex(unsigned int p_node_id, const BVH_ABB<AABB,Vector3> & p_added_item_aabb) Line 269 (c:\Users\Matheus\Downloads\Godot Source\core\math\bvh_split.inc:269)
BVH_Tree<GodotCollisionObject3D,2,2,128,GodotBroadPhase3DBVH::UserPairTestFunction<GodotCollisionObject3D>,GodotBroadPhase3DBVH::UserCullTestFunction<GodotCollisionObject3D>,1,AABB,Vector3>::split_leaf(unsigned int p_node_id, const BVH_ABB<AABB,Vector3> & p_added_item_aabb) Line 191 (c:\Users\Matheus\Downloads\Godot Source\core\math\bvh_split.inc:191)
BVH_Tree<GodotCollisionObject3D,2,2,128,GodotBroadPhase3DBVH::UserPairTestFunction<GodotCollisionObject3D>,GodotBroadPhase3DBVH::UserCullTestFunction<GodotCollisionObject3D>,1,AABB,Vector3>::_logic_choose_item_add_node(unsigned int p_node_id, const BVH_ABB<AABB,Vector3> & p_aabb) Line 212 (c:\Users\Matheus\Downloads\Godot Source\core\math\bvh_logic.inc:212)
BVH_Tree<GodotCollisionObject3D,2,2,128,GodotBroadPhase3DBVH::UserPairTestFunction<GodotCollisionObject3D>,GodotBroadPhase3DBVH::UserCullTestFunction<GodotCollisionObject3D>,1,AABB,Vector3>::item_add(GodotCollisionObject3D * p_userdata, bool p_active, const AABB & p_aabb, int p_subindex, unsigned int p_tree_id, unsigned int p_tree_collision_mask, bool p_invisible) Line 60 (c:\Users\Matheus\Downloads\Godot Source\core\math\bvh_public.inc:60)
BVH_Manager<GodotCollisionObject3D,2,1,128,GodotBroadPhase3DBVH::UserPairTestFunction<GodotCollisionObject3D>,GodotBroadPhase3DBVH::UserCullTestFunction<GodotCollisionObject3D>,AABB,Vector3,1>::create(GodotCollisionObject3D * p_userdata, bool p_active, unsigned int p_tree_id, unsigned int p_tree_collision_mask, const AABB & p_aabb, int p_subindex) Line 118 (c:\Users\Matheus\Downloads\Godot Source\core\math\bvh.h:118)
GodotBroadPhase3DBVH::create(GodotCollisionObject3D * p_object, int p_subindex, const AABB & p_aabb, bool p_static) Line 38 (c:\Users\Matheus\Downloads\Godot Source\servers\physics_3d\godot_broad_phase_3d_bvh.cpp:38)
GodotCollisionObject3D::_update_shapes() Line 177 (c:\Users\Matheus\Downloads\Godot Source\servers\physics_3d\godot_collision_object_3d.cpp:177)
GodotCollisionObject3D::_shape_changed() Line 236 (c:\Users\Matheus\Downloads\Godot Source\servers\physics_3d\godot_collision_object_3d.cpp:236)
GodotPhysicsServer3D::_update_shapes() Line 1736 (c:\Users\Matheus\Downloads\Godot Source\servers\physics_3d\godot_physics_server_3d.cpp:1736)
GodotPhysicsServer3D::body_test_motion(RID p_body, const PhysicsServer3D::MotionParameters & p_parameters, PhysicsServer3D::MotionResult * r_result) Line 920 (c:\Users\Matheus\Downloads\Godot Source\servers\physics_3d\godot_physics_server_3d.cpp:920)
PhysicsServer3DWrapMT::body_test_motion(RID p_body, const PhysicsServer3D::MotionParameters & p_parameters, PhysicsServer3D::MotionResult * r_result) Line 263 (c:\Users\Matheus\Downloads\Godot Source\servers\physics_server_3d_wrap_mt.h:263)
PhysicsBody3D::move_and_collide(const PhysicsServer3D::MotionParameters & p_parameters, PhysicsServer3D::MotionResult & r_result, bool p_test_only, bool p_cancel_sliding) Line 109 (c:\Users\Matheus\Downloads\Godot Source\scene\3d\physics\physics_body_3d.cpp:109)
CharacterBody3D::_move_and_slide_grounded(double p_delta, bool p_was_on_floor) Line 159 (c:\Users\Matheus\Downloads\Godot Source\scene\3d\physics\character_body_3d.cpp:159)
CharacterBody3D::move_and_slide() Line 108 (c:\Users\Matheus\Downloads\Godot Source\scene\3d\physics\character_body_3d.cpp:108)
call_with_validated_variant_args_ret_helper<CharacterBody3D,bool>(CharacterBody3D * p_instance, bool(CharacterBody3D::*)() p_method, const Variant * * p_args, Variant * r_ret, IndexSequence<> __formal) Line 375 (c:\Users\Matheus\Downloads\Godot Source\core\variant\binder_common.h:375)
call_with_validated_object_instance_args_ret<CharacterBody3D,bool>(CharacterBody3D * base, bool(CharacterBody3D::*)() p_method, const Variant * * p_args, Variant * r_ret) Line 663 (c:\Users\Matheus\Downloads\Godot Source\core\variant\binder_common.h:663)
MethodBindTR<CharacterBody3D,bool>::validated_call(Object * p_object, const Variant * * p_args, Variant * r_ret) Line 537 (c:\Users\Matheus\Downloads\Godot Source\core\object\method_bind.h:537)
GDScriptFunction::call(GDScriptInstance * p_instance, const Variant * * p_args, int p_argcount, Callable::CallError & r_err, GDScriptFunction::CallState * p_state) Line 1989 (c:\Users\Matheus\Downloads\Godot Source\modules\gdscript\gdscript_vm.cpp:1989)
GDScriptInstance::callp(const StringName & p_method, const Variant * * p_args, int p_argcount, Callable::CallError & r_error) Line 1970 (c:\Users\Matheus\Downloads\Godot Source\modules\gdscript\gdscript.cpp:1970)
Node::_gdvirtual__physics_process_call<0>(double arg1) Line 351 (c:\Users\Matheus\Downloads\Godot Source\scene\main\node.h:351)
Node::_notification(int p_notification) Line 62 (c:\Users\Matheus\Downloads\Godot Source\scene\main\node.cpp:62)
Node::_notificationv(int p_notification, bool p_reversed) Line 49 (c:\Users\Matheus\Downloads\Godot Source\scene\main\node.h:49)
Node3D::_notificationv(int p_notification, bool p_reversed) Line 52 (c:\Users\Matheus\Downloads\Godot Source\scene\3d\node_3d.h:52)
CollisionObject3D::_notificationv(int p_notification, bool p_reversed) Line 38 (c:\Users\Matheus\Downloads\Godot Source\scene\3d\physics\collision_object_3d.h:38)
PhysicsBody3D::_notificationv(int p_notification, bool p_reversed) Line 41 (c:\Users\Matheus\Downloads\Godot Source\scene\3d\physics\physics_body_3d.h:41)
CharacterBody3D::_notificationv(int p_notification, bool p_reversed) Line 38 (c:\Users\Matheus\Downloads\Godot Source\scene\3d\physics\character_body_3d.h:38)
Object::notification(int p_notification, bool p_reversed) Line 902 (c:\Users\Matheus\Downloads\Godot Source\core\object\object.cpp:902)
SceneTree::_process_group(SceneTree::ProcessGroup * p_group, bool p_physics) Line 965 (c:\Users\Matheus\Downloads\Godot Source\scene\main\scene_tree.cpp:965)
SceneTree::_process(bool p_physics) Line 1050 (c:\Users\Matheus\Downloads\Godot Source\scene\main\scene_tree.cpp:1050)
SceneTree::physics_process(double p_time) Line 492 (c:\Users\Matheus\Downloads\Godot Source\scene\main\scene_tree.cpp:492)
Main::iteration() Line 3983 (c:\Users\Matheus\Downloads\Godot Source\main\main.cpp:3983)
OS_Windows::run() Line 1673 (c:\Users\Matheus\Downloads\Godot Source\platform\windows\os_windows.cpp:1673)
widechar_main(int argc, wchar_t * * argv) Line 181 (c:\Users\Matheus\Downloads\Godot Source\platform\windows\godot_windows.cpp:181)
_main() Line 206 (c:\Users\Matheus\Downloads\Godot Source\platform\windows\godot_windows.cpp:206)
main(int argc, char * * argv) Line 220 (c:\Users\Matheus\Downloads\Godot Source\platform\windows\godot_windows.cpp:220)
WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 234 (c:\Users\Matheus\Downloads\Godot Source\platform\windows\godot_windows.cpp:234)
[Inline Frame] invoke_main() Line 102 (d:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:102)
__scrt_common_main_seh() Line 288 (d:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
kernel32.dll!00007ffeaf277344() (Unknown Source:0)
ntdll.dll!00007ffeaf63cc91() (Unknown Source:0)

Also some pics with (maybe useful?) extra info:

would this not just disallow generation of blocks with a negative coordinate, as this should be possible.

Ah, sorry, I misunderstood how gridmap works. It actually ranges from -1mil to +1mil

I tested the code and was able to get a backtrace

And that gives us the answer. It looks like the sheer number of collision objects is causing the crash.
Maybe this is a bug as it's not supposed to crash, but it's also going to be slow even if it wasn't...
Suggestion
Use two gridmaps. One for the visual data, that renders however far you'd like, and one for collision that only has the few chunks the player stands in is loaded.
Also, currently every block has it's own material and an identical copy of the source pixel art texture like "Snow_Blocks_PixelArt.png" and "Coal_Blocks_PixelArt.png". If they shared the same material and texture (and not have backface culling disabled) then the framerate can go up a lot.

@matheusmdx @huwpascoe
Ah yes, thank you so much guys. I'll give it a go now :D

I did some extra investigation and what i found:
The cause of crash is a implict conversion that happens here:
https://github.com/godotengine/godot/blob/71699e08c9df78b7203fa4ef9cede28e995d6ace/core/templates/pooled_list.h#L88-L90
https://github.com/godotengine/godot/blob/71699e08c9df78b7203fa4ef9cede28e995d6ace/core/templates/pooled_list.h#L56-L58

As you can see the U value is a uint32_t in this template and for some reason tnode.get_leaf_id() is returning a negative value (-2) here
https://github.com/godotengine/godot/blob/71699e08c9df78b7203fa4ef9cede28e995d6ace/core/math/bvh_misc.inc#L41-L44

The uint32_t variable can't hold negative values, so the code treats the -2 as an overflow and wraps to 4294967294. tnode.get_leaf_id() returns the value of tnode.neg_leaf_id inverting the signal, so that means tnode.neg_leaf_id for some reason is receiving a non-negative value and when tnode.get_leaf_id() inverts the signal, transforms the result in a negative value
https://github.com/godotengine/godot/blob/71699e08c9df78b7203fa4ef9cede28e995d6ace/core/math/bvh_structs.inc#L112-L129
Considering my assumption is correct, the last question is why tnode.neg_leaf_id is receiving a non-negative value (and is always the same value, 2)

I'm having this same exact problem with my Terraria-like tile generation on bigger maps on the latest version.
ERROR: FATAL: Index p_index = 4294967294 is out of bounds (count = 32772).    at: operator[] (./core/templates/local_vector.h:177)
Could we possibly get an engine fix for this?

My comment is not as technical as the one from @matheusmdx but I still add my experience here in case it helps debugging.
In my case I am working in a voxel game also using gridmap cells where each cell is a "block" in my game but each of those cells can have more than one collision but most of the time there is a single collision per cell, so if the number of collisions to handle is what matters here we could say that in average there are around 1.5 collisions per cell (this is relevant for the cell count I show below).
My game is not procedurally generating scenes, instead I have pre-made full scenes, which I call "rooms" and each of them have up to more than a million gridmap cells that have to be loaded at once. More over, I pre-load adjacent rooms too which would add to the total cells processed.
With this said I might be able to add a bit of helpful info to this issue. I have the exact same crash message as in the original post but only if I hit a specific number of gridmap cells used:
The engine loads, instantiates and adds to the main_tree all these cells without having the crash, BUT crashes right after so maybe related with rendering or collision detection calculations. I don't know:
Current Room: 0003_big_plains
- GridMap 'GridMapRiver1' has 1229 cells
- GridMap 'GridMapRiver2' has 223 cells
- GridMap 'GridMapNorthWest' has 466818 cells
- GridMap 'GridMapNorthEast' has 536627 cells
- GridMap 'GridMapSouthWest' has 513413 cells
- GridMap 'GridMapSouthEast' has 346987 cells

Adjacent Room: 0002_vertical_passage
- GridMap 'GridMapWater' has 97101 cells
- GridMap 'GridMap' has 390991 cells

Adjacent Room: 0005_another_cave
- GridMap 'GridMap' has 265767 cells

Total cells across all rooms (current + adjacent): 2619156

Now, if I simply delete the "GridMapWater" from room 0002_vertical_passage then there are now crashes and the total cell count is as follows:
Current Room: 0003_big_plains
- GridMap 'GridMapRiver1' has 1229 cells
- GridMap 'GridMapRiver2' has 223 cells
- GridMap 'GridMapNorthWest' has 466818 cells
- GridMap 'GridMapNorthEast' has 536627 cells
- GridMap 'GridMapSouthWest' has 513413 cells
- GridMap 'GridMapSouthEast' has 346987 cells

Adjacent Room: 0002_vertical_passage
- GridMap 'GridMap' has 390991 cells

Adjacent Room: 0005_another_cave
- GridMap 'GridMap' has 265767 cells

Total cells across all rooms (current + adjacent): 2522055

The strange thing is that I actually do room.process_mode = Node.PROCESS_MODE_DISABLED for the adjacent rooms even before they are attached to the main tree, so in theory in the first scenario (with crash) and the second scenario (no crash) the number of cells that are simultaneosly being rendered and processed somehow, should be exactly the same number... this together with the fact that in the first scenario the crash happens after all is instantiated and added to the main tree makes me think that regardless of those adjacent rooms having process disabled the total cell count (or the collisions total count) is still adding up to a number that makes some internal process (that comes after all is loaded, instantiated and added to the current scene) crash.
Since this would limit what I can do and don't and I would have to design my game around this limit, it would be good to know if this is a limit of the engine or an actual bug.

authors: AlexLovelock22 diegopau huwpascoe matheusmdx xCISACx


text:
TileSetEditorPlgn: Fix a leak

fixes #17061
Thanks Rubonnek!

Nothing to cherry-pick actually, there was no leak in AutotileEditor in 3.0.

It is actually fixed before 3.0 by #15963 but reintroduced in #16742.
@damarindra is this revert intentional?

I think @damarindra missed a few changes when rebasing their branch on top of the current master, and some fixes were lost.

@Noshyaar Thanks for fixing this!

Sorry for it, will be more careful next time.

authors: Noshyaar Rubonnek akien-mga damarindra


text:
Fix VisualScript Change Base Type title

Fixes #28939
I didn't see any reason not to make the CreateDialog popup as a change dialog, but if this has consequences I don't know of, please let me know!

Can you post a screenshot of before and after?

Before:

After:

Thanks!

authors: Jummit akien-mga fire


text:
Fix PopupMenu's letter jumping on any InputEventKey (instead of just a press)

fixed #37355

I just found #36734, which includes a fix to my opened issue (and some more stuff).
I only searched through the open issues and not PRs/proposals. Should I close/delete this PR? Sorry, still new to all of this.

No I think this PR can be kept, it's easy to review and merge/cherry-pick to fix a well-defined issue.
#36734 has a bigger scope and might be more controversial (for example change the default value of a member variable depending on whether it's running in the editor or not is a bit hacky).

Thanks!

Cherry-picked for 3.2.2.

authors: Leleat akien-mga


text:
Rename File's endian_swap to big_endian

This new name is more consistent with ResourceSaver and StreamPeer.
See https://github.com/godotengine/godot/issues/16863#issuecomment-844633192.

Thanks!

authors: Calinou akien-mga


text:
Respect disabled animation tracks

Fixes #25537, supersedes #60509

Thanks!

authors: akien-mga reduz


text:
Optimize animation blend tree process

Optimize animation blend tree process.
Fixes #65199 (Partially)
In #57675 and #62623, for blending result consistency, it was necessary to blend animations even if the blend amount is 0 or don't have sync option.
The fundamental reason of this is that the blend values are initialized only on the track that will be blended in the only one frame that is just played.
Consistent blending by correct initialization:
https://user-images.githubusercontent.com/61938263/201505301-54ed7bd6-b2c6-4922-ace5-32c5464a43b8.mp4
Inconsistent blending due to lack of initialization on certain tracks:
https://user-images.githubusercontent.com/61938263/201505307-6861b234-792b-42f4-9288-86fdede7dfaf.mp4
This PR separates the initialization process and iterates through the TrackCache instead of the track that will be blended at that frame. This greatly reduces calculation cost while keeping the blending consistency. Well, this is just a re-implementation of the optimization that #57675 removed.
I confirmed that this would increase the FPS of the https://github.com/godotengine/godot/issues/65199#issuecomment-1247090562 project at running by about 1.5 times.
Before:

After:

Also, these are the projects to check whether this PR will not change the behavior:
animation_blend_test.zip
character_controller_3d_sample.zip
As far as I have checked, this PR should not change the behavior of the blending, but I welcome anyone who is interested to test it. This is mention to people I remember talking about optimization before: @JoanPotatoes2021 @and-rad
This process optimization was the biggest issue, so I think we can now close #65199 for now. If this does not solve the problem of frame rate dropping with panning viewport, then perhaps it is a problem other than blending.

Thanks!

This (or something related) may have caused the regression described in #69066
It's the only Animation-related PR listed on the release notes in between beta5 and beta6.

I think that issue has already been fixed in the follow-up PR, see 68993.

Off topic, but something about those Suzanne-headed humanoids feels very uncomfortable.
Where can I get them?

There it is in the project for benchmarking uploaded by @JoanPotatoes2021 in https://github.com/godotengine/godot/issues/65199#issuecomment-1247090562, but I don't know if you can use it as you want, just ask @JoanPotatoes2021. Yeah, Humanoid Suzanne is not cute, but I think it's nice as the enemy model.

authors: TokageItLab akien-mga atirut-w zacryol


text:
import: Prevent _Wheel nodes not parented to VehicleBody3D

Check that _Wheel node satisfies the requirement of being a direct child of a VehicleBody3D before converting to a VehicleWheel3D.
This seems like a reasonable fix, since the current behavior will cause an error by adding the VehicleWheel3D without complying with the node's constraint of being a direct child of a vehicle.

This is also one of the few suffixes recognized by Godot that is also a common english word, so it is more likely to be encountered by users.
The other two english word node types are "vehicle" and "rigid", but these also have specific meaning in terms of physics.
Fixes #72419

P.S. (I'm a little uncertain why Godot chops off the node type from nodes converted in this way. I find it confusing, and it could also cause conflicts, for example if I have two nodes in the source document with distinct names which are validated by the glTF importer, but then they become the same name. See this screenshot:

Test blend file: test_col_import.blend.zip

Implementation doesn't work. Apparently _pre_fix_node recurses to children before processing, so I can't tell what type my parent is.

Now that we have https://github.com/godotengine/godot/pull/96745, this PR may be unnecessary. Users can disable node type suffixes if they do not want wheels to be generated. This will also stop other things from being generated, but those can be specified at other stages instead, such as before in the glTF importer itself, or after using the Advanced Import Settings dialog.

authors: aaronfranke lyuma


text:
TextureProgressBar Update upon texture changes

Makes sure TextureProgressBar is updated on changed signal of any texture assigned to it. The same thing is already being done e.g. for TextureRect:
https://github.com/godotengine/godot/blob/caf7a72b029803041bee37708bfdc9de60170eca/scene/gui/texture_rect.cpp#L198-L215
Fixes #75531.

The repetitive code could be replaced by a macro probably, but is fine as is.

If desired I could move it to a new method so the existing methods would look like:
void TextureProgressBar::set_under_texture(const Ref<Texture2D> &p_texture) {
	_set_texture(under, p_texture);
}

That's if under (and alike) would be passed be reference. But I think we don't like passing like this in the code base?:thinking: So instead could be passed by pointer like _set_texture(&under, p_texture); which is clearer from the caller side.

idk about property pointers, but if it works, it can be a method.

idk about property pointers, but if it works, it can be a method.

You've convinced me to make that change. :upside_down_face:

This is better.
But while testing, I accidentally found a bug. Not sure if it's worth fixing.
When you assign the same texture to 2 slots and remove it from one of them, the other slot will stop receiving the signal (because the texture disconnects).
The only way to fix this is to connect each of these methods to unique callable. Either make 3 different methods, or bind one method 3 times and use Callable(this, "_texture_changed_n").

When you assign the same texture to 2 slots and remove it from one of them, the other slot will stop receiving the signal (because the texture disconnects).

Indeed, good point.

The only way to fix this is to connect each of these methods to unique callable. Either make 3 different methods, or bind one method 3 times and use Callable(this, "_texture_changed_n").

Actually the fix should be trivial, the connection can be ref counted (so only after the matching number of disconnects it will actually disconnect).

Actually the fix should be trivial, the connection can be ref counted

Right, I forgot this exists 🙃

Thanks!

Cherry-picked for 4.0.3.

Not sure if this should go here but it feels like it is related: As of 4.0.3, changing the region of an AtlasTexture at runtime does not call queue_redraw on a TextureButton (but it does on a TextureRect). Is it part of this fix coming in 4.1 or should I open a new request about it? (or maybe this is intended? My experience is still minimal, so I might be missing something. Couldn't find anything about this in forums and such though)

@SomeMedtnerGuy See #77159

authors: KoBeWi SomeMedtnerGuy YuriSizov akien-mga kleonc


text:
[3.x] Downgrade android gradle plugin to version 7.2.1.

Version 7.3.0 changes the build layout which causes updates to the generated shared libraries to not be picked up.
main version

Cherry-picked for 3.5.3.


text:
Avoid multiple possibilites of deadlock in resource loading

Multi-threaded resource loading can deadlock if one of the current load tasks are waiting for another which hasn't still started running to complete and all the low-priority slots in the WorkerThreadPool are occupied. This PR allows the WorkerThreadPool to detect such a situation and schedule additional low-prio tasks until the situation is solved.
Since the WorkerThreadPool needs to count how many low-prio threads are awaiting on others, this PR also needed to add support for multiple waiters. Otherwise, the ResourceLoader would use its own waiting mechanism for tasks already awaited, which would prevent such count from being exhaustive.

Another possibility of deadlock is that a worker thread in the WorkerThreadPool, upon one task waiting for another, runs yet another task over the stack frame of the awaiting one. That can lead to a load task eventually waiting for a previous one which can no longer finish because it's "buried" in the stack. Many possibilites have been assessed and discarded (enrich the worker pool with some task dependency info, avoid burying tasks' stack frames and even adding support for fibers for easy task switching within a given thread). The approach here is let the WorkerThreadPool detect the fact and report ERR_BUSY to the caller. In this PR the ResourceLoader is trained to catch the problem and apply a workaround.

This PR also ensures there's always at least one high-priority thread in the pool.

Thanks!

authors: RandomShaper akien-mga


text:
Make TouchScreenButton connections reference counted

Prevents errors when assigning the same texture to both slots
Follows up on #75016, which was cherry picked

I'll just go ahead and remove it, took it from other usage to clarify

Thank you!


text:
Add EditorStringNames singleton

This PR adds EditorStringNames singleton, complementary to CoreStringNames and SceneStringNames. It includes some most common theme-related StringNames: Editor, EditorFonts, EditorIcons and EditorStyles. More strings can be added later (e.g. most common types or most common constant/stylebox names etc.).
This results in lower memory usage of the editor (I didn't do any benchmark though) and slightly better performance in some cases (especially initializing the theme might be faster I think).
I also included a macro EditorStringName(name), which is a shorthand for EditorStringNames::get_singleton()->name, making the code much less verbose. We could add such macro to other StringName singletons too.

Benchmark
Startup/shutdown times
❯ hyperfine -iw1 "bin/godot.linuxbsd.editor.x86_64 --quit" "bin/godot.linuxbsd.editor.x86_64.master --quit"
Benchmark 1: bin/godot.linuxbsd.editor.x86_64 --quit (this PR)
  Time (mean ± σ):      2.740 s ±  0.056 s    [User: 1.390 s, System: 0.225 s]
  Range (min … max):    2.619 s …  2.841 s    10 runs

Benchmark 2: bin/godot.linuxbsd.editor.x86_64.master --quit
  Time (mean ± σ):      2.690 s ±  0.066 s    [User: 1.394 s, System: 0.220 s]
  Range (min … max):    2.591 s …  2.768 s    10 runs

Summary
  bin/godot.linuxbsd.editor.x86_64.master --quit ran
    1.02 ± 0.03 times faster than bin/godot.linuxbsd.editor.x86_64 --quit

❯ hyperfine -iw1 "bin/godot.linuxbsd.editor.x86_64 /tmp/4/project.godot --quit" "bin/godot.linuxbsd.editor.x86_64.master /tmp/4/project.godot --quit"
Benchmark 1: bin/godot.linuxbsd.editor.x86_64 /tmp/4/project.godot --quit (this PR)
  Time (mean ± σ):      4.768 s ±  0.425 s    [User: 3.847 s, System: 0.380 s]
  Range (min … max):    4.169 s …  5.171 s    10 runs

Benchmark 2: bin/godot.linuxbsd.editor.x86_64.master /tmp/4/project.godot --quit
  Time (mean ± σ):      4.808 s ±  0.376 s    [User: 3.851 s, System: 0.388 s]
  Range (min … max):    4.402 s …  5.173 s    10 runs

Summary
  bin/godot.linuxbsd.editor.x86_64 /tmp/4/project.godot --quit ran
    1.01 ± 0.12 times faster than bin/godot.linuxbsd.editor.x86_64.master /tmp/4/project.godot --quit

Binary size
Stripped Linux x86_64 editor binary (optimize=none, no LTO):
150,776,656  godot.linuxbsd.editor.x86_64 (this PR)
151,126,640  godot.linuxbsd.editor.x86_64.master

That's a reduction of 350 KB, nice :slightly_smiling_face:
Peak memory usage
Average of 3 runs, opening editor on empty project then quitting:
829,358,000 godot.linuxbsd.editor.x86_64 (this PR)
829,777,000 godot.linuxbsd.editor.x86_64.master

Think this might need a restart and the search/replace applied more carefully

I used a script to do that. I don't see any other way to do a non-trivial replacement in 1600+ lines. Luckily GitHub's diff makes it easy to spot wrong replacements.

Meant to check different cases in the replace script, one of the issues was probably caused by greedy search, as it grabbed all between quotes somehow

I'd say to use a regex to replace all the trivial cases, checking that it's exactly a string in the area, and then use some search method to identify all the cases that aren't trivial

Thanks! Now rebasing begins 😬

authors: AThousandShips Calinou KoBeWi YuriSizov


text:
Expose PopupMenu activate_item_by_event method

Fixes #40836
Exposes the method that Controls like MenuButton use to propagate input information to the PopupMenu, so that accelerator and shortcut functionality isn't limited to those Controls.

Could this be added to the 4.2 milestone? The reason I did this PR is because a serious project I'm working on depends on it.
If not, I'll just use my own fork until it gets merged.

If it gets approved soon it'll be added to it, but enhancements fit more on a flexible schedule

If it gets approved soon it'll be added to it, but enhancements fit more on a flexible schedule

Got it, thanks for the quick answer.

I've tested this PR with my project. From what I can tell, everything works as intended.

Thanks!


text:
Allow FSR to downscale

Closes https://github.com/godotengine/godot-proposals/issues/8086.
Removes the limitation on FSR not being allowed to downscale from higher resolutions.
From my testing:
FSR benefits surprisingly from being allowed to downscale, but that's to be expected perhaps since fundamentally FSR is just a spatial upscaler.
FSR 2 doesn't see as much benefit in static, unmoving scenes. To be expected perhaps due to its temporal superscaler nature. The benefits are primarily in clarity while in motion and the reduction of disocclusion artifacts. (when scale is set to 2.0, disocclusion artifacts are almost completely gone)

CC @DarioSamo @Calinou

Rebased my commits.

why wasn't downsampling supported previously

Concerns about oversharpening. However anyone choosing to downsample will be able reduce or remove FSR sharpening in the project settings, and sometimes maybe a user actually does want the oversharpened look - they should be able to have it.

While I did stick to following the behavior FSR1 had in the existing codebase, I'm unsure as to whether this is a valid use case. I noticed it works as a happy accident, but it definitely doesn't in solutions like DLSS or XeSS (causes visible corruption even). While it's true we don't have either of those, this is not going to be true for every upscaler out there, so I'm mostly wary of this due to UX concerns.
That said I feel the resolution scale options above 1.0 aren't exactly working as intended, as I haven't noticed the existence of downsampling passes to properly account for it. It sounds like we'd be better served by doing something like maintaining FSR2 at native resolution when going above 1.0 (e.g. pretend input and display resolution is the same) and using something like AMD FidelityFX Single Pass Downsampler to downscale the result.
If we can find anything in FSR2 that showcases this behavior is expected in the API I think we're fine to do it, but I've been unable to find anything about it.

For me the most important usage of this feature is keeping the look of FSR 2 even when you slightly overshoot the scale.
https://github.com/godotengine/godot-proposals/assets/39361911/bac1685e-3bd2-41f0-8609-097dd742acaf
Honestly, I doubt most people will actually want to use FSR 2 as a downsampler in earnest.
Perhaps I could put the WARN_PRINT_ONCE back and replace the warning with "FSR 3D resolution scaling is not designed for downsampling. Consider using bilinear 3D resolution scaling."? So that we can keep this as an interim solution until proper FSR downscaling can be added. (In case AMD confirms that downscaling is not supported)

For me the most important usage of this feature is keeping the look of FSR 2 even when you slightly overshoot the scale.

That's a pretty real concern when I saw how it was handled. I think there's two solutions here:

From GDScript side you can definitely just clamp it to 1.0.
The comparison in C++ should check with a tolerance (e.g. (1.0 + 1e-6f)) instead of 1.0 directly.

as I haven't noticed the existence of downsampling passes to properly account for it.

We indeed lack a dedicated downsampling shader. We should eventually have one for better quality for Movie Maker mode recordings. This would allow using resolution scales above 2.0 without graininess, but VRAM utilization is an issue at such high resolution scales anyway (temporal supersampling is preferable to spatial supersampling for this reason).

From GDScript side you can definitely just clamp it to 1.0.

This was my first thought as well, but it felt like "lying" to the user in a sense - if the user selects 1440p, they're gonna expect 1440p, even if their monitor is only 1080p. Similar to how people wanting higher quality videos on Youtube will select 1440p even if they only have 1080p monitors.
While native FSR 2 antialiasing is currently very good, there are still artifacts here and there due to its TAA nature (mostly some blurriness while in motion and some disocclusion artifacts), and even with this potentially unintended use case, a higher internal resolution (when setting higher scaling with this PR) does alleviate these artifacts. So I feel there is still validity in allowing this PR as an interim solution, until proper downscale behavior as you've described -

maintaining FSR2 at native resolution when going above 1.0 (e.g. pretend input and display resolution is the same) and using something like AMD FidelityFX Single Pass Downsampler to downscale the result

- is implemented. Proper downscaling should definitely be implemented eventually though, it's the behavior you'd intuitively expect when downscaling.

I haven't noticed the existence of downsampling passes to properly account for it

From what I can tell with this PR it is indeed actually not downsampling at all, at least not in the way a user would normally expect. Rather, the extra pixels due to the higher internal resolution seem to be properly used, but the resolve itself is still at native. But this makes sense, because this is exactly how FSR 2 works in the opposite direction - when using lower internal resolutions, the resolve is obviously at native - that's the appeal of this tech in the first place after all.

Rather, the extra pixels due to the higher internal resolution seem to be properly used, but the resolve itself is still at native.

The hardware is able to do box downsampling up to 2×2 with a smooth result that doesn't exhibit graininess (however, it's not always sharp at non-integer scale factors). At greater scales, mipmap generation or a dedicated downsampling shader is required.

I meant the FSR 2 resolve itself is at native - I think with the current behavior with this PR, there is no actual downsampling happening when you set the scaling above 1.0. You're just feeding more pixels into the FSR 2 machine than you'd normally be able to. Compared to what happens when you use TAA + bilinear scaling for example: an TAA'd image at 1440p is rendered, then bilinear downscaled to 1080p.

Tested locally, it works as expected. However, the result with FSR2 and a 2.0 scale factor is generally more aliased than TAA with a 2.0 scale factor:
Bilinear
Scale 1.0

Scale 2.0

FSR 2.2 (Sharpness = 2.0, lowest)
Scale 1.0

Scale 2.0

For high-quality rendering, FSR2 with 8× MSAA is likely preferable if you want to minimize aliasing on moving edges. Alternatively, you could render more frames than will be saved in the video, which will also improve the quality of other effects that converge over several frames (including motion blur once it's implemented)./

authors: Calinou DarioSamo Jamsers akien-mga


text:
Update GPUParticles3D.xml

Clarified the finished signal, as it is incorrect to say that the signal is issued once processing of all active particles have finished (at least according to the GitHub thread that explained this to me).
This time, modifying the XML file.

Here is where I am explained that the particle emitter will emit the finished signal once the particles are no longer visible: https://github.com/godotengine/godot/pull/76859
What I see in my test project concurs: the finished signal is received before the emitter is ready to emit, yet there are no particles visible on the screen.

Here is where I am explained that the particle emitter will emit the finished signal once the particles are no longer visible: #76859

What I meant when I said that, is that I can guarantee you that the particles will no longer be visible. But that doesn't mean that they are necessarily still processed.

Here is where I am explained that the particle emitter will emit the finished signal once the particles are no longer visible: #76859

What I meant when I said that, is that I can guarantee you that the particles will no longer be visible. But that doesn't mean that they are necessarily still processed.

But that is, in my opinion, not relevant for the game developer. The only thing that is relevant is that when the finished signal is received, the game developer can call restart() with no risk of popping particles off screen. In other words, when finished is received, the particles may or may not be processing, but are either way no longer visible.
This is why I suggest the wording in my PR.

To clarify: I am in favor of adding clarification about this to the docs.
But we need to make a difference between intended behavior and the current situation.
We should not change the part that says Emitted when all active particles have finished processing IMO. It is the intended behavior and we can't remove the intended behavior from the docs. (It's especially important here, to keep consistent with the CPU particle nodes.)
That the node thinks it is processing for longer than the particles are visible does not sound like intended and defined behavior on the other hand. It's a quirk in the current code which would better be placed inside a Note:.

Also when we find a suited modification for the docs. You should copy it over to the 2D GPU particles as well.

To clarify: I am in favor of adding clarification about this to the docs.
But we need to make a difference between intended behavior and the current situation.
We should not change the part that says Emitted when all active particles have finished processing IMO. It is the intended behavior and we can't remove the intended behavior from the docs. (It's especially important here, to keep consistent with the CPU particle nodes.)

Well, I thought we were documenting how things work, and not how we would like it to work? I would assume a future release that changes this, will be responsible for updating the docs? Surely this is how it should be?

That the node thinks it is processing for longer than the particles are visible does not sound like intended and defined behavior on the other hand. It's a quirk in the current code which would better be placed inside a Note:.

I just want the docs to be actual helpful. As it is written, I wasted hours messaging to understand why the node was still emitting (i.e. true) even after having received finished.

Well, I thought we were documenting how things work, and not how we would like it to work? I would assume a future release that changes this, will be responsible for updating the docs? Surely this is how it should be?

If a future release were to change things it would change nothing about the implementation of this signal. The signal is working as it should be. So I see no ground for changing it's behavior description based on, what I would call, undefined behavior at an other point.
Side Note:
I am no core dev so arguing with me about the philosophy of writing docs won't help the situation. It's my personal opinion on how to write docs that help both developers and users.

I just want the docs to be actual helpful.

:+1:

As it is written, I wasted hours messaging to understand why the node was still emitting (i.e. true) even after having received finished.

So first of all emitting is false when the signal finished (except you set it yourself). That's just how it is implemented. (Put simple: Emitting will be set to false after half of the lifetime)
The thing that needs clarification is that setting emitting to true won't guarantee the system to start even when emitting was false before. This fact has little to do with this signal. It was true in 4.1 as well.
emitting is just not the right way to start a one shot particle system. And something like this could go into the docs (preferably for the emitting properties description).

I believe the edit is now finally covering all feedback.
Sorry for taking up so much of your time. This has been a great learning experience, and I am very grateful for all comments! Thank you so much to everyone that took part!
If Godot is developed with the same level of care as this doc-change, then that makes me very happy. Godot will keep getting better, and I'll do everything I can to help out. Albeit more efficiently next time.
Any more comments or feedback?

Now all it needs is a review. Do I ask for the review somewhere?

Still needs an approving review, but also you need to squash commits together into one. You can wait for an approval to make sure you don't need to make further edits, but you will need to do this eventually before we can merge.
Make sure that the final commit has a short but descriptive message (the title of this PR is a good option). See this documentation, if you need help with squashing.

OK, so I squashed and give the commit a succinct description.

Thanks! And congrats for your first merged Godot contribution :tada:

Thanks, though far from my first. I had one in Oct 2022 as well ;-)

My bad! Might have been from a different GitHub account as GitHub doesn't seem to remember it: https://github.com/godotengine/godot/commits?author=Gatada

I am not sure how these repos work, but here it is:
https://github.com/godotengine/godot-docs/commits/master?author=gatada

authors: Gatada HolonProduction YuriSizov akien-mga


text:
Fix README from linuxbsd_headers

This PR fixes formatting & spelling errors and bad/dead links in thirdparty/linuxbsd_headers/README.md

Thanks!

authors: akien-mga programneer


text:
Add tests for AnimationPlayer

Added file test_animation_player.h under tests/scene.
File contains tests cases for methods set_default_blend_time, get_default_blend_time, set_blend_time and get_blend_time.
Modified test_main.cpp to include the new test file.
EDIT: forgot to link to issue #43440 (sorry).

Since most of your code is commented out I'd suggest making this a draft until you're done, or remove the commented out code

I need to add a test to guard #97760. Should I add my test there, since this thread seems still ongoing?

authors: AThousandShips EAinsley JustSascha