text:
WIP: Fix review notifications and add them to mail templates

This PR fixes a panic produced while creating reviews, and adds review comments to the notification mail template.

@lunny I've marked the PR WIP for your consideration, although it's already functional.
It turns out that the review service was the wrong place to add the notifications, as they were already being added a few lines below where the comment is created.
What I'd suggest to follow the "services" model is to move most of routers/repo/pull_review.go to services/pull/review.go (which I removed because it was only calling models now). Perhaps that can be done in a future PR to keep this PR simple.

Codecov Report

Merging #8948 into master will increase coverage by 0.01%.
The diff coverage is 18.75%.

@@            Coverage Diff             @@
##           master    #8948      +/-   ##
==========================================
+ Coverage   41.23%   41.25%   +0.01%
==========================================
  Files         547      546       -1
  Lines       70794    70801       +7
==========================================
+ Hits        29195    29207      +12
+ Misses      37880    37870      -10
- Partials     3719     3724       +5

Impacted Files
Coverage Δ

models/issue_comment.go
48.07% <ø> (+0.21%)
:arrow_up:

routers/repo/pull_review.go
0% <0%> (ø)
:arrow_up:

modules/notification/mail/mail.go
26.56% <0%> (-2.26%)
:arrow_down:

services/mailer/mail.go
43.88% <26.08%> (-2.42%)
:arrow_down:

modules/migrations/migrate.go
21.22% <0%> (-1.68%)
:arrow_down:

modules/migrations/gitea.go
8.05% <0%> (-0.64%)
:arrow_down:

models/repo.go
46.46% <0%> (-0.05%)
:arrow_down:

models/repo_list.go
74.07% <0%> (+0.92%)
:arrow_up:

models/error.go
33.86% <0%> (+1.18%)
:arrow_up:

modules/task/migrate.go
28.94% <0%> (+3.94%)
:arrow_up:

... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7b97e04...86f906a. Read the comment docs.

Example review mail:

Close in favor of #8954
I can add the template stuff later, since the work is already done. 😁


text:
feat:add before find hook

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

What did this pull request do?
Add Before Find Hook.
I find that gorm do not implemention before find hook, but the document mentioned.

User Case Description

We don't support BeforeFind by design. https://gorm.io/docs/hooks.html#Querying-an-object
The dest is usually an empty struct before querying, so we don't support BeforeFind due to it might increase misusages

source: gharchive/pull-request

repo: go-gorm/gorm

license: MIT

license_type: permissive

license_source: github-api


text:
Embedded static resources

Proposal
Go's 1.16 new embed feature is great to bundle static resources into the binary, making it easier to distribute it. Currently, the frameworks relies on a non-interfaced filesystem, which makes it a bit harder to use embedded resources. Only the configuration supports it. I would like to provide a solution for developers wanting to embed their files.

Create a new handler similar to router.Static(), but taking io/fs.FS as a parameter.
Add the ability to use an io/fs.FS to load language files. (This may require a bit of refactoring into the framework so it's possible to load a language file by file)
Provide an abstracted version of the helper/filesystem package so it works with io/fs too.
Allow Request to use generic file system.

On top of adding the ability to embed files, this would also let developers use virtual filesystems and fetch files from other sources more easily. However, the io/fs packge is still a bit young in my opinion, and lacks interfaces for writable FS. I wouldn't want to create a temporary non-standard interface that will probably not be compatible with a potential future standard one. So for now, this issue will stay on standby until more development on the io/fs package.
Because the embed feature is only available in go 1.16+ and that the io.FS interface is required for what I would like to achieve here, we can't build this into the framework without breaking compatibility with prior versions. I don't want to stop supporting older versions (yet), so we could create an external library. Later on, we could consider merging this library into the framework. With v4, I dropped go versions < 1.16.
Possible drawbacks
None.
Additional information
This issue is a feature proposal and is meant to be discussed. The design is not set yet neither.
It is also a good candidate if you want to contribute to the project.

Check how wails v2 handles embedded assets. We could take inspiration from this.

Fully supported in v5.

source: gharchive/issue

repo: go-goyave/goyave


text:
fix: prometheus with multiple providers

we encountered an issue where tegola would panic if you'd try to register duplicate metrics collectors.
that would happen if you have more than one mvt provider in the same config file.
this fix would append the provider name to the metric name. to ensure backward compatibility the provider name would only be appended if there were more than one.
Would also resolve #886

Pull Request Test Coverage Report for Build fe6fc3add-PR-903

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

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

atlas/atlas.go
0
12
0.0%

Totals

Change from base Build b358d4df0:
-0.04%

Covered Lines:
5745

Relevant Lines:
12686

💛  - Coveralls

I'm still looking at this. This was my initial idea (as well), but I want to make sure it makes sense.  Also, why do we need both the array of prefixes and the hash map?

var prefixWithProvider bool
{
   var (
       mvtProviderSet = make (map[string]struct{})
      value = struct{}{}
   )
   for _, aMap := range a.maps {
        mvtProviderSet[aMap.mvtProviderName] = value
   }
   prefixWithProvider = len(mvtProviderSet) > 1
}
var prefix = "tegola"
for _, aMap := range a.maps {
     if prefixWithProvider {
        prefix = fmt.Sprintf("tegola_%s",aMap.mvtProviderName())
    }
    collectors, err := aMap.Collectors(prefix,o.CollectorConfig)
   if err != nil {
       log.Errorf("failed to register collector (%s) for map: %s ignoring", prefix, aMap.Name)
      continue
   }

   if err = o.Register(collectors...); err != nil {
      log.Error("failed to register collectors %+v",err)
     panic(err)
   }
}

Would it be okay to break compatibility a bit here? Breaking compatibility will be changing the name of the observer key from tegola, to tegola_mvt_provider_name; if I'm reading this correctly. If willing, that could be handled in the postgis collector method.
I'm still tracing the code to make sure I understand what exactly is going on. Wanted to get my thoughts out as I have already dropped the ball on this once.

Cool, was not aware that Len() works on a map like that, which is why I'm jumping hoops there.
You're not breaking compatibility with this change, as previously it was not possible to track more than one provider with prometheus.
You are correct however, that ideally we'd re-use the same metric but distinguish different providers with a tag, similar to how you distinguish maps right now.

I found a solution using labels instead. I will close this PR and open a new one with a cleaner approach. Thank you anyway for taking the time and going through this with me @gdey 🙏

authors: coveralls gdey iwpnd

repo: go-spatial/tegola


text:
SetMessageReaction not working

Hello, I'm testing your library, great work.
One thing that I'm having trouble with is SetMessageReaction, I get errors when using it.
I'm able to make it work by defining a custom MarshalJSON like so:
func (rt *ReactionType) MarshalJSON() ([]byte, error) {
	if rt.Type == ReactionTypeTypeEmoji {
		return json.Marshal(rt.ReactionTypeEmoji)
	}
	if rt.Type == ReactionTypeTypeCustomEmoji {
		return json.Marshal(rt.ReactionTypeCustomEmoji)
	}
	return nil, fmt.Errorf("unsupported ReactionType type")
}

This creates the reaction but returns one error:
error decode response result for method setMessageReaction, json: Unmarshal(non-pointer bool)

I'm not sure why.

Fixed in v1.1.2

authors: crossworth negasus

repo: go-telegram/bot


text:
Missing dist/index.js file

Hello Kento.
I'm wondering if you could advise where I can find the  dist/index.js that is needed for docker build command?
I was trying to build docker image but it's failing at this step:
------
 > [stage-0 2/4] COPY dist/index.js /var/task/index.js:
------
Dockerfile:5
--------------------
   3 |     WORKDIR /
   4 |
   5 | >>> COPY dist/index.js /var/task/index.js
   6 |
   7 |     COPY --from=aquasec/trivy:latest /usr/local/bin/trivy /opt
--------------------
ERROR: failed to solve: failed to compute cache key: failed to calculate checksum of ref 2f512eb0-cd8e-4fc9-ab30-f25de56bb2bc::5pru0a83adkb3wrboq1r5ol8f: "/dist/index.js": not found

View build details: docker-desktop://dashboard/build/desktop-linux/desktop-linux/knht8rml3wyh2wdoqo82o4eu4

@airmonitor
Thanks for your reporting!
You just run npm(yarn) install image-scanner-with-trivy if you use this library in your CDK code.
If you customize or run (build) it locally, you can run npx projen build for building it, then the next command will be run:

https://github.com/go-to-k/image-scanner-with-trivy/blob/main/.projenrc.ts#L82-L87
https://github.com/go-to-k/image-scanner-with-trivy/blob/main/.projen/tasks.json#L86-L98

(About yarn build, see below:)

https://github.com/go-to-k/image-scanner-with-trivy/blob/main/assets/lambda/package.json#L8

This library builds the code before publishing to npm in CI.

https://github.com/go-to-k/image-scanner-with-trivy/blob/main/.github/workflows/build.yml#L29

authors: airmonitor go-to-k

repo: go-to-k/image-scanner-with-trivy


text:
[FEATURE-REQUEST] Support Github Dark Mode

I had github in dark mode and was woundering about the black icons... See screenshot.
( https://github.com/settings/appearance )

Same

Agreed! Maybe put an background behind the icons :)

authors: LarsFlieger SecretAyee conradkirschner

repo: goabstract/Awesome-Design-Tools


text:
Print version on new line

When running packr version, it should print the version on it's own line.
Current behavior:
$ packr version
v2.5.3$

New behavior:
$ packr version
v2.5.3
$

When checking the recommended behavior against Cobra, their example uses Println, as well.
var versionCmd = &cobra.Command{
  Use:   "version",
  Short: "Print the version number of Hugo",
  Long:  `All software has versions. This is Hugo's`,
  Run: func(cmd *cobra.Command, args []string) {
    fmt.Println("Hugo Static Site Generator v0.9 -- HEAD")
  },
}

Yes, please! This would be super nice to have 🙌

Sorry for the delay, and thanks!

authors: ksenish laynemcnish stanislas-m

repo: gobuffalo/packr


text:
DumpSchema can log database credentials

When running soda migrate -d in a project using Pop, the last line logged out when the schema is dumped can contain the database URL and therefore the username and password used to connect to it:
    "[POP] 2018/02/21 21:53:23 pg_dump -s --dbname=postgres://USERNAME:PASSWORD@host:5432/app?sslmode=disable"

This project is using -d to make the SQL being run against the database in the migrations visible, but ideally we can avoid leaking credentials in order to achieve that.
The code that logs this message is in postgresql.go in DumpSchema, although I imagine that it also affects some of the other database types.
I'd like to address this issue and am planning to open a pull request to do so. My initial thought was to just not print out the database URL and avoid the issue that way. What do you think of that approach?

I'm torn. The -d flag is meant for debugging purposes, which could include trying to figure out why it's not connecting, and hiding the connection info takes away from the intended purpose of the flag.
On the other hand, we don't want to leak information. The simple solution is to just not use the -d flag in production, then the info is safe.
But I'm open to suggestions on how to maintain the usefulness of the -d flag, but at the same time, make it secure.

What do you think about having soda migrate print some other output as each migration is run? We wouldn't need to use -d to gain this insight or complicate how the debug output was currently being handled.
How about something like this:
$ soda migrate up
v3.51.1
Migrating up...
  20180103215841_create_posts
  20180205233329_create_comments

0.0209 seconds
dumped schema for datebase_name

This could be the default, which I think would be OK, or hidden behind a flag.

I believe the default for migrate is to print the name of the migrations and the times. Adding the database it’s migrating would be a good addition.

You're right! I had missed that.
I think I'll close this for now, as the immediate need is already supported. Thanks for helping me work through this issue.

No worries. Happy to help. 🙂

authors: jim markbates

repo: gobuffalo/pop


text:
Add unit tests for match function in analytics controller

This will address issue: Unit tests for crane #91
If you have any problems with the test names please let me know

@alierkilic thanks for you contribution, you can combine your unit test into one like :https://github.com/gocrane/crane/blob/main/pkg/controller/ehpa/hpa_test.go#L6

Should I mock the function calls inside Reconcile, SetupWithManager and createRecommendation? I don't see gomock used in the project.

@alierkilic mock testing are wanted! you don't see those tests because we are still focusing on core feature development. It's perfect if you can start from such tasks.

can you squash commits of this PR?

@mfanjie I will start working on it

@alierkilic you can still refine this pr and merge the commit, more UT can be done in separated PR.

@mfanjie can you accept this PR? If the merge commit is a problem, I can force push an older head, merge and then add my changes. It was like that before. I think I accidentally closed it.

plz squash commits

suggest to simplify the description

done

/lgtm

authors: alierkilic mfanjie qmhu

repo: gocrane/crane


text:
add exclude filters upon exporting game

add exclude filters upon exporting game

this should resolve issue #12

repo: godot-rust/godot-rust-template


text:
There's no way to track active statuses

We have to keep quite a bit of globals like foo_entered or whatever:
:hand
> [!foo_appeared]
    set_active foo true
    set_global foo_appeared true

Wouldn't it be cool to use this instead?
:hand
set_active foo true [!a/foo]

This would mirror the magic of i/ being inventory items, but a/ would mean the active status.
Opinions?

At first I found this syntax quite unclear at reading. But I guess it's much easier when you know it.
I'm fine with this syntaxic sugar if the previous method is kept valid. :)

Of course you can use set_global to do whatever you want, but I have to say I found i/ unclear as well at first ;)
Let's see if/when I get around to implementing a/ but tracking this stuff has been an issue a couple of times, so it would be a welcome addition.
If there's another syntax you'd prefer, I'm open to suggestions, but I couldn't come up with anything better...
'active/foo` is pretty verbose and there's an impedance with how inventory works :/

No I think a/foo is fine. If "a" is ever found to mean something else better than "active", then we'll see what to do. Anyway "active" seems to be very used to I fully agree to let "a" mean "active".

authors: StraToN mjtorn

repo: godotengine/escoria


text:
ProjectSettings.get_setting doesnt work

Godot version:

Godot 3.0.2
OS/device including version:

Linux Mint 17.2 x86_64
Issue description:

Hi
I could not load AdMob Module from https://github.com/kloder-games/godot-admob
Steps to reproduce:

download
https://github.com/kloder-games/godot-admob/tree/master/admob into admob folder
https://github.com/godotengine/godot into ~/godot-3.0.2-stable
put admob folder to ~/godot-3.0.2-stable/modules
execute the following commands

cd ~/godot-3.0.2-stable
scons platform=x11
scons platform=android target=release -j 4
cd platform/android/java
./gradlew build
cd ../../..
scons platform=android target=release_debug -j 4
cd platform/android/java
./gradlew build
cd ../../..

execute godot.x11.tools.64
create a new project and new main scene with its script
select Project->Project Settings->General
add new property
Category:	Android
Property: Modules
Type    : String
value   : org/godotengine/godot/GodotAdMob
Select Project->Export->Android->Options
add android_debug.apk and android_release.apk into Custom Package
add ProjectSettings.has_setting("AdMob") into one the script you have
and It shows false(expected true)

NOTE:
The instructions/docs still uses earlier Godot version:
engine.cfg instead of project.godot
Globals.get_singleton instead of ProjectSettings.get_setting
I can only use project.godot and ProjectSettings
Minimal reproduction project:

You should use Engine.get_singleton().
Issues with third party modules should be reported to the module repos, and only here if you establish with the module maintainer that the issue comes from the engine itself.
In this case, there's even a Godot 3 example showing you how to use it: https://github.com/kloder-games/godot-admob/blob/master/examples/godot-3/main.gd

thanks.I'll keep that in mind. sorry for the trouble

authors: akien-mga houfaru

repo: godotengine/godot


text:
Inspector: "Object was deleted while awaiting a callback" on complex Resource load

Godot version:
1ff772b
OS/device including version:
Windows 10 x64
Issue description:
I'm assuming this might have something to do with how the new inspector works.  Upon attempting to load a large TileSet resource for a tilemap, the console gets spammed ad infinitum with the error message "Object was deleted while awaiting a callback" and the editor becomes unresponsive.  This particular tileset resource doesn't always make 3.0.6 very happy either, but although it makes the editor stall for input when loading, it is still usable there.
This tileset can be loaded at runtime without an issue, but attempting to inspect the resource at design time will result in this soft lock.  Any node instances which utilize the tileset as a subresource become impossible to inspect at design time as well.
Steps to reproduce:
Create a new project and extract the contents of the archive to root.  Attempt to load the resource.
Minimal reproduction project:
complexTileset.zip

I also had this error (Object was deleted while awaiting a callback) when resizing a ColorRect Node, this was the structure:

Node2D

CanvasLayer

Control

Control

ColorRect

I was modifying the size x value of that Rect.
After a minute throwing that error the flood stopped and got this
TOTAL BYTES: 1048560
NULL count: 0
CALL : 43684
CALL _update_callback: 3
CALL show_modal: 1
CALL grab_focus: 1
CALL select_all: 1
ERROR: Message queue out of memory. Try increasing 'message_queue_size_kb' in project settings.
   At: core/message_queue.cpp:56

Godot: v3.1.alpha.official

I am affected by this problem as well, also in simple scenes. I can't determine a common scheme that allows an easy reproduction of this bug. I'll push my repo and link it on this issue.

@straton
What kind of assets were they?  Was there anything unusual about them?

@nobuyukinyuu Nothing special. All were from Kenney's assets, both 2D and 3D stuff - but many of them.

I personally have an infinite loop of this messages randomly when I'm starting a game/scene from the editor. When it happens it's linked with editor freeze and rapid memory leak.

Removing project folder from Roaming\Godot\projects fix the problem for me.

Should be fixed by #24194.

authors: PLyczkowski StraToN akien-mga coppolaemilio kubecz3k nobuyukinyuu


text:
Cannot load resource which has a C# script attached to it

Godot version:

8068d0217a5e74c25f83fe93fa6e077b8d0b3bf5
OS/device including version:

Linux
Issue description:

If you try to load a resource which has a C# script attached to it, the game will silently crash when played with no errors reported in the editor console.  This will happen in GDScript using load or preload, in C# using Load or Load<T>, or exporting a Resource variable and placing the resource into that slot via the editor.
Steps to reproduce:

Create a new resource
Attach a C# script to it which inherits 'Resource'
Try to load the resource in any way

NoCSRes.zip

CC @neikeq

Tried it again with 220f50e790223c7bc63fd3d2ca3327aa6dcc5d3c
Right now, it gives this error in the terminal:
ERROR: _load: No loader found for resource: res://
   At: core/io/resource_loader.cpp:192.

And in the Debugger/Errors tab:
E 0:00:00:0834   System.NullReferenceException: Object reference not set to an instance of an object
  <C Source>     :0
  <Stack Trace>  :0 @ ()
                 ResourceLoader.cs:36 @ Godot.Resource Godot.ResourceLoader.Load(System.String , System.String , Boolean )()
                 ResourceLoaderExtensions.cs:7 @ Godot.SpatialMaterial Godot.ResourceLoader.Load<Godot.SpatialMaterial >(System.String )()
                 TestNode.cs:9 @ void TestNode._Ready()()

Using the following code:
using Godot;
using System;

public class TestNode : Node
{
	public override void _Ready()
	{
		var res = ResourceLoader.Load<SpatialMaterial>("res://TestRes.tres");
		GD.Print(res);
	}
}

TestRes.tres has a C# script attached to it:
using Godot;
using System;

public class MyTestRes : SpatialMaterial
{
	[Export]
	public int MyInt { get; private set; }
	[Export]
	public string MyString { get; private set; }
}

Trying this exact same thing on any other resource without a C# script, there's no issue:
	public override void _Ready()
	{
		var res = ResourceLoader.Load<SpatialMaterial>("res://SomeMaterial.tres");
		GD.Print(res);
	}

Casting to SpatialMaterial or MyTestRes makes no difference for the resource with the C# script.  If the script is removed, it loads fine.

Can't reproduce the crash in 3.1 beta 6, it seems to load fine.

authors: akien-mga somnivore


text:
Animation Player moves ui out of screen

When opening the Animation player editor, it shift the ui to the right, and the only way to get it back is close the ui and resize the screen.

The same issue is reported on #3469, but using a window tiled to the side of the screen.

I got a similar issue when showcasing Godot at FOSDEM using a beamer, it was quite annoying, I could not find a way to see the inspector. I don't remember if the AnimationPlayer was involved though.

I can confirm this with screen resolution 1280x720. It looks like animation editor's upper icons take too much space, so the whole Godot window is expanded to the right and going out of the screen. In the same time, when animation editor is opened, left or right Scene, FileSystem or Inspector panels can't be resized. After closing animation editor everything is back to normal, except the right edge of Godot's window is still outside the screen edge.
The bug looks the same in maximized window and fullscreen mode.
I think somewhat IMPORTANT info:
The bug is present (at lease with screen resolution 1280x720) ONLY when Scene, FileSystem or Inspector panels use both, left and right panels at the same time.
When Scene, FileSystem or Inspector panels are moved to one side, left or right, then the screen expands to the right, but does not go off the screens edge and the Scene, FileSystem or Inspector panel CAN be resized.

authors: LeonardMeagher2 akien-mga freemanfromgodotengine vnen


text:
Implementing a generic interface with a type paramter of a generic class's inner class causes a build error

Godot version:
Godot Engine v3.2.2.rc.mono.custom_build.36a30f681
Commit: 36a30f681fc8c3256829616f32ee452b15674752
Also encountered on a 3.2.1-stable build, earlier versions not tested.
OS/device including version: 5.4.24-1-MANJARO x86_64 GNU/Linux
Issue description:
In C#, implementing a generic interface with the inner-member of a generic class causes godot to raise an error on build per source file. These errors do not stop the build from completing and the resulting build appears to work.
Error message:
modules/mono/glue/gd_glue.cpp:250 - Failed to determine namespace and class for script: <script name>.cs. Parse error: Unexpected token: .
Steps to reproduce:

Create generic class with a public inner class
Implement a generic interface, using that inner class as the generic parameter
Press build, note error in output but a functional build.

Minimal reproduction project:
Test.tar.gz

We have a very basic parser to collect qualified names in 3.x, in 4.0+ we replaced the parser with source generators so this won't be a problem there.
Since these kinds of issues don't prevent the game from building and running it may not be worth fixing it for 3.x at this point, changing the basic parser risks breaking things more. As a workaround you may be able to use aliases in some cases.
There is another related issue with generics in the parser: #43751

authors: notverymoe raulsntos


text:
Assign a static function result to a constant not works

Godot version:
Godot Engine v3.2.1.stable.official - https://godotengine.org
OpenGL ES 2.0 Renderer: GeForce GTX 980/PCIe/SSE2
OS/device including version:
Windows 10 (64x)
Issue description:
I try to create a constant value on my class by assignment a value created by a static function.
I guess it should work because a const variable is like a final static variable.
The Godot documentation says:

cConstant names if they contain a script resource (MyScript if you declared const MyScript = preload("res://my_script.gd")).

So I would expect it should work with static functions to
Steps to reproduce:

create a new GsScript and put this lines into

static func encodeModuleId(id:int, orientation:int) -> int:
	return orientation<<16|id

const DEFAULT_ID = encodeModuleId(-1, 0)

res://assets/wfc/sampler/constVar.gd:7 - Parse Error: Expected a constant expression.
modules/gdscript/gdscript.cpp:576 - Method failed. Returning: ERR_PARSE_ERROR

Minimal reproduction project:

gdscript const are compile time constants, and thats why preload() works but not load() since load and every other functions (including static) are called at run time. Also not every static functions could be const folded, they may return different values at different states, consider a static function returns the current time.

got it, you can close it

authors: MikeSchulze ThakeeNathees


text:
get_aabb() returns AABBs with incorrect position-values

Godot version:
Godot v3.2.3.rc6.official
OS/device including version:
MacBook Pro (13", 2020)
2,3 GHz Quad-Core Intel Core i7
16 GB 3733 MHz LPDDR4X
Intel Iris Plus Graphics 1536 MB
Issue description:
I hope that this is not a conceptual misunderstanding on my end but it seems to me that the position property of AABBs is reporting incorrect values.

extends Spatial

func _ready():
	print($box1.get_aabb())
	print($box2.get_aabb())
	print($box2.get_aabb())

Running this code on the scene shown above yields the following output:

-0.5, -0.5, -0.5 - 1, 1, 1
-0.5, -0.5, -0.5 - 1, 1, 1
-0.5, -0.5, -0.5 - 1, 1, 1

As one can see all position values are identical despite the cubes being positioned differently.
Originally I assumed that this was by design and that one would have to offset the AABBs utilising the object's origin-coordinate to get the correct position of the AABB in the global world. But that surely can't be right as this would result in varying / wrong values depending on where the origin is positioned in relation to the actual geometry.
Steps to reproduce:
See above
Minimal reproduction project:
200915_Godot_AABB.zip

Did you find a solution to this issue?

@Calinou : I thought I did. But by now I am even more stumped. :) Right now I am just unsure if this is a bug or an issue on my end which is why I did not reopen things.
I have come to realise that the AABBs never reflect position, rotation and scale of instances. get_aabb() always leads to the bounding box of the unrotated, unscaled object positioned at the origin resulting in false collision detection. Position can be accounted for by altering the AABBs position-property according to the instance's origin but I am fairly stumped now as to how to account for rotation and scale. Sadly I can't find too much information on the whole AABB topic in Godot in general.

As I still can't seem to find a solution here is an illustration of the issue. It is still the basic code form above.
Scene in perspective

Intersection false

Intersection true

extends Spatial

func _ready():
	var b1 = $box1.get_aabb()
	var b2 = $box2.get_aabb()

	b1.position += $box1.translation
	b2.position += $box2.translation

	print(b1.intersects(b2))

As one can see what matters is not the actual position / rotation / scale (as seen on the left side of the images) but the default rotation where in the 2nd one this leads to a small intersection while in reality both versions should report "true" as the bounding boxes should intersect.

Could you check if get_transformed_aabb gives you the right result? It looks like get_aabb is the bounding box in local space, while get_transformed_aabb is in world space.

Yeh, that was the obvious solution I was afraid of potentially just not seeing. So yeah, thanks, that worked!
I guess the method is not documented in https://docs.godotengine.org/de/stable/classes/class_aabb.html for being inherited from VisualInstance?

authors: Calinou okapii pouleyKetchoupp


text:
Referencing VERTEX in a canvas item shader causes large offset relative to screen size.

Godot version:
3.2.4 Beta 1 mono GLES3
OS/device including version:
Windows 10
Issue description:
Referencing VERTEX in a canvas item shader causes large offset relative to screen size.

Steps to reproduce:

Open a new project.
Add a sprite with a texture.
Add a shader to the canvas item with the following code:

shader_type canvas_item;

void vertex() {
	vec2 the_vertex = VERTEX;
}

Minimal reproduction project:
shaderBug.zip

@markdibarry Can you reproduce this in 3.2.3?

I cannot. This is a bug introduced in 3.2.4

Likely related to GLES3 batching.

Likely duplicate of #42899 wind custom shader problem which was fixed by #43054.
(can't test this as away from home, but anyone with latest 3.2 build should be able to try.)

I was having the same problem, but now I tried with the latest 3.2 build and it seems fixed.

I didn't know there was a new build released. I must have missed it. Sorry! Closing.

While the fix has been merged, you would probably have to compile 3.2 dev branch yourself to make a build, until 3.2.4 beta 2 is released.
No need to be sorry, duplicate issues of new features do happen, and we would rather have them if you aren't sure it is caused by the same bug. :+1:

authors: Calinou ailernx akien-mga lawnjelly markdibarry


text:
[3.2.3] Crash while click on a node in the nodetree

Godot version:
3.2.3-stable
OS/device including version:
Operating System: Manjaro Linux
Kernel Version: 5.10.4-arch2-1-vfio
Graphics Processor: AMD Radeon™ Vega 8 Graphics
amdgpu, GLES3
Issue description:
I was playing with the visual shader screen and then I clicked on of the nodes in the node tree.
Also there were a lot of same messages in the console like this:
ERROR: _copy_texscreen: Can't use screen texture copying in a render target configured without copy buffers.
At: drivers/gles3/rasterizer_canvas_gles3.cpp:1341.
Not sure if it is related to the crash
Steps to reproduce:
I tried to do something similar I did, but no success.
handle_crash: Program crashed with signal 11
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[1] /usr/lib/libc.so.6(+0x3d6a0) [0x7f74847306a0] (??:0)
[2] /home/*/projects/Godot_v3.2.3-stable_x11.64() [0x292257e] (??:?)
[3] /home/*/projects/Godot_v3.2.3-stable_x11.64() [0x20ff5e9] (??:?)
[4] /home/*/projects/Godot_v3.2.3-stable_x11.64() [0x2101481] (??:?)
[5] /home/*/projects/Godot_v3.2.3-stable_x11.64() [0x213c3d7] (??:?)
[6] /home/*/projects/Godot_v3.2.3-stable_x11.64() [0x1f2aed5] (<artificial>:?)
[7] /home/*/projects/Godot_v3.2.3-stable_x11.64() [0x2904e49] (??:?)
[8] /home/*/projects/Godot_v3.2.3-stable_x11.64() [0xc579b3] (??:?)
[9] /home/*/projects/Godot_v3.2.3-stable_x11.64() [0xc612d6] (??:?)
[10] /home/*/projects/Godot_v3.2.3-stable_x11.64() [0xc622d0] (??:?)
[11] /home/*/projects/Godot_v3.2.3-stable_x11.64() [0x21bbb51] (<artificial>:?)
[12] /home/*/projects/Godot_v3.2.3-stable_x11.64() [0x2904e49] (??:?)
[13] /home/*/projects/Godot_v3.2.3-stable_x11.64() [0xc579b3] (??:?)
[14] /home/*/projects/Godot_v3.2.3-stable_x11.64() [0x91e6ed] (??:?)
[15] /home/*/projects/Godot_v3.2.3-stable_x11.64() [0xc657fc] (??:?)
[16] /home/*/projects/Godot_v3.2.3-stable_x11.64() [0x18e74a9] (??:?)
[17] /home/*/projects/Godot_v3.2.3-stable_x11.64() [0x298fc05] (??:?)
[18] /home/*/projects/Godot_v3.2.3-stable_x11.64() [0x85ce4d] (??:?)
[19] /usr/lib/libc.so.6(__libc_start_main+0xf2) [0x7f748471b152] (??:0)
[20] /home/*/projects/Godot_v3.2.3-stable_x11.64() [0x86b68e] (??:?)

@Voaz That backtrace isn't useful since official binaries don't contain debugging symbols. Could you try to reproduce the crash with a debug build?

Closing due to lack of response, if you provide the requested information this can be reopened

authors: AThousandShips Calinou Voaz


text:
Automatic focus issue of ScrollContainer's ScrollBar

Godot version:

3.3 rc8
OS/device including version:

Issue description:

ScrollContainer's ScrollBar won't get automatic focus when mouse cursor isn't on it or is on it but doesn't do any operation
it maybe not a issue but I think it's missing feature
Steps to reproduce:
https://user-images.githubusercontent.com/64188282/113996988-4b3b0500-988a-11eb-8312-dd9e45f30a56.mov
Minimal reproduction project:

project_ui.zip

ok I figure out why it is not automatic focus, there is a mistake in my code, sorry 😓，I will close this issue and also give the right code below if anyone need it


text:
Rigidbody2D jitters on FPS drops

Godot version: 3.3
Platforms: MacOS, Android
Issue description:
Hello there. I'm making a racing game. Player car and other cars are Rigidbody2D type objects. Gameplay is very smooth at 60 FPS. But sometimes even a little drop in FPS(50-55) causes rigidbodies to jitter. How do I fix that (except keep fps at 60. Because it will be a mobile game and maybe not everyone able to play it on 60 FPS). I tried both versiyon 3.2.3 and 3.3
Physics jitter fix: 0.5
Code looks something like this (I can send more detailed if needed):
func _physics_process(delta):
    if speed>speed_limit:
            thrust = Vector2(0, 0)
    else:
            thrust = Vector2(engine_power, 0)
    set_applied_force(thrust.rotated(rotation))

Steps to reproduce:
Set your project FPS limit to 50. Set physics FPS to 60. Apply force to a Rigidbody2D. You will see object jitters.
Bugsquad edit: For reference, this was cross-posted on Godot forums: https://godotforums.org/discussion/26109/rigidbody2d-jitters-on-fps-drops

See https://docs.godotengine.org/en/stable/tutorials/misc/jitter_stutter.html and this addon: https://github.com/lawnjelly/smoothing-addon

See https://docs.godotengine.org/en/stable/tutorials/misc/jitter_stutter.html and this addon: https://github.com/lawnjelly/smoothing-addon
it only works if physics FPS is lower than screen FPS.

it only works if physics FPS is lower than screen FPS.

The smoothing add-on can still do its job even if the physics FPS is equal to rendering FPS.

it only works if physics FPS is lower than screen FPS.

The smoothing add-on can still do its job even if the physics FPS is equal to rendering FPS.
Out of curiosity, are you using a Camera2D node with smoothing enabled? Try changing its update mode to Process instead of Idle.
Yes I have camera2D node smoothing on. It follows player car. I disabled it and changed mode to process. This time both camera and rigidbody jitters together (road jitters relatively).

This should be resolved with the addition of fixed timestep interpolation. It's currently only available in 3D, but it'll be ported to 2D eventually (after 3.5 is released).

Closing per the above comment.


text:
Crash during engine shutdown if get_tree() is ever called from GDNative

Godot version:
3.3 stable
OS/device including version:
Windows 10
Issue description:
If get_tree() is ever called from a GDNative plugin then Godot will crash on shutdown when you quit your game.
The crash occurs in NativeScriptLanguage::free_instance_binding_data.
free_instance_binding_data is entered but godot_gdnative_terminate has already been called at this point so the function pointer is invalid.
This doesn't happen in Godot 3.2.
Steps to reproduce:
Call get_tree() from a GDNative class, run your game with a debugger attached and quit.
Minimal reproduction project:
gdnative_get_tree_crash.zip
This is the only relevant part AFAIK:
class Test : public godot::Node {
	GODOT_CLASS(Test, godot::Node);
public:
	static void _register_methods() {
		register_method("_ready", &Test::_ready);
	}
	void _init(){}
	void _ready() {
		get_tree();
		// Godot will now crash in NativeScriptLanguage::free_instance_binding_data()
	}
};

Can confirm this occurs on macOS Big Sur too, where it's worse because the user will be greeted with a crash report window every time they exit.

Related to #46844, #47655, and #47623.
CC @godotengine/gdnative @geekrelief @toasteater @Bromeon

I can confirm this happens with godot-cpp (Win10 + MSVC) but doesn't happen with godot-nim or with the C godot-headers. I only have basic familiarity with godot-cpp, but I'll try to help debug this.

Note that godot-cpp hasn't been updated yet to match the 3.3-stable release, so that may be part of the problem.
This might get solved once this update is done.

Thanks!  Hopefully, you spared me the trouble of debugging this. I was in the middle of trying to bisect the godotengine to commits to see which commit was the cause.

Note that godot-cpp hasn't been updated yet to match the 3.3-stable release, so that may be part of the problem.
This might get solved once this update is done.

Is there any effort towards figuring out how to synchronize this stuff better? It sounds like there is always going to be a window of several weeks after every Godot release where c++ projects are not going to work. Frustrating for existing developers who do not realise that they need to wait for godot-cpp to catch up, and confusing for new c++ developers who are simply following the instructions in the godot-cpp readme.

I can't reproduce the crash on Linux, though if I use a godot-cpp commit before https://github.com/godotengine/godot-cpp/pull/552 and don't upgrade the headers manually, I do get errors:
ERROR: open_dynamic_library: Can't open dynamic library: /home/akien/tmp/godot/bug/gdnative_get_tree_crash/project//bug/bin/x11/libbug.so. Error: /home/akien/tmp/godot/bug/gdnative_get_tree_crash/project//bug/bin/x11/libbug.so: undefined symbol: _ZN5godot25EditorSceneImporterAssimp23___init_method_bindingsEv
   At: drivers/unix/os_unix.cpp:415.
ERROR: get_symbol: No valid library handle, can't get symbol from GDNative object
   At: modules/gdnative/gdnative.cpp:502.
ERROR: init_library: No nativescript_init in "res:///bug/bin/x11/libbug.so" found
   At: modules/gdnative/nativescript/nativescript.cpp:1479.
ERROR: terminate: No valid library handle, can't terminate GDNative object
   At: modules/gdnative/gdnative.cpp:407.

But with that PR merged and the new 3.3 branch it seems to work just fine.
Could you confirm that updating the headers fixes the issue for you?

Could you confirm that updating the headers fixes the issue for you?

No, on Windows the same crash is occurring with the new 3.3 branch.

This crash was happening to me and it somehow stopped. It could be VS not fully rebuilding project after updating the headers?

On Windows 8.1 it's not crashing for me right now.
It (get_tree()->exit()) was crashing for some time at the beginning after I moved project to 3.3 but I think it was VS that didn't fully rebuild project after I updated headers from 3.2 to 3.3???
The problem I got is that godot editor is locking gdnative dll for writing. I have to restart godot editor  every time I change dll.
https://github.com/godotengine/godot/issues/48086

The issue I reported isn't that get_tree() is crashing though. Calling get_tree() at any point simply sets Godot up to crash during program shutdown. get_viewport also causes the crash and probably any other method that goes through the ___godot_icall_Object wrapper. This is still occurring with the 3.3 headers after doing a full clean and rebuild.
Stack trace of the crash:
>	godot.windows.tools.64.exe!NativeScriptLanguage::free_instance_binding_data(void * p_data) Line 1365	C++
 	godot.windows.tools.64.exe!Object::~Object() Line 2049	C++
 	godot.windows.tools.64.exe!MainLoop::~MainLoop() Line 81	C++
 	godot.windows.tools.64.exe!SceneTree::~SceneTree() Line 2176	C++
 	[External Code]
 	godot.windows.tools.64.exe!memdelete<MainLoop>(MainLoop * p_class) Line 119	C++
 	godot.windows.tools.64.exe!OS_Windows::delete_main_loop() Line 1799	C++
 	godot.windows.tools.64.exe!Main::cleanup(bool p_force) Line 2243	C++
 	godot.windows.tools.64.exe!widechar_main(int argc, wchar_t * * argv) Line 164	C++
 	godot.windows.tools.64.exe!_main() Line 184	C++
 	godot.windows.tools.64.exe!main(int _argc, char * * _argv) Line 196	C++
 	[External Code]

This might be stupid question sorry but are you building project by scons file or in VS?

The reproduction project I attached in the OP uses cmake to generate a VS project.

My project was crashing at exit (in export and editor) after some time after updating to 3.3 and somehow stopped crashing. I am calling get_tree().quit() in gd script, but in many gdnative scripts I have plenty get_viewport()-> calls.
I checked your plugin.cpp file and I think it misses constructor and destructor:
Example:
GDExample();
~GDExample();

The constructor and destructor is irrelevant. The issue is that the plugin's godot_gdnative_terminate has already been called by the time NativeScriptLanguage::free_instance_binding_data is entered so free_instance_binding_data points to an invalid address.

Still relevant on 3.3.1

I tried again and I finally managed to reproduce the crash on Linux. It doesn't seem to happen when running the project through the editor, but it does when running standalone.
Here's a fixed MRP so that it builds properly against godot-cpp godot-3.3.3-stable (with renamed godot_headers to godot-headers, and fixed path for Linux library).
How to use:
cd godot-cpp
cmake -DCMAKE_BUILD_TYPE=Debug .
make -j
cd ..
cmake -DCMAKE_BUILD_TYPE=Debug -DGODOT_CPP_ROOT=godot-cpp .
make -j
cd project
godot

Crash backtrace (from 3.3.4 RC e4df8a68fa9d2e35c1710dd952b1f9337e7e2f46, but that's close enough to 3.3.3 stable):
#0  0x00007fffa01e3497 in ?? ()
#1  0x0000000001bb284f in NativeScriptLanguage::free_instance_binding_data (this=0x7667dc0, p_data=0x7e995a0) at modules/gdnative/nativescript/nativescript.cpp:1363
#2  0x0000000004304168 in Object::~Object (this=0x7adcc60, __in_chrg=<optimized out>) at core/object.cpp:2047
#3  0x00000000044349bc in MainLoop::~MainLoop (this=0x7adcc60, __in_chrg=<optimized out>) at core/os/main_loop.cpp:81
#4  0x000000000348063e in SceneTree::~SceneTree (this=0x7adcc60, __in_chrg=<optimized out>) at scene/main/scene_tree.cpp:2176
#5  0x000000000170fd8d in memdelete<MainLoop> (p_class=0x7adcc60) at ./core/os/memory.h:117
#6  0x0000000001708b12 in OS_X11::delete_main_loop (this=0x7fffffffce20) at platform/x11/os_x11.cpp:2913
#7  0x000000000174522d in Main::cleanup (p_force=false) at main/main.cpp:2241
#8  0x00000000016fa7e9 in main (argc=1, argv=0x7fffffffd728) at platform/x11/godot_x11.cpp:57

It appears this workaround can be added to user code to suppress the crash
extern "C" void GDN_EXPORT godot_gdnative_terminate(godot_gdnative_terminate_options * o)
{
	Godot::nativescript_terminate(godot::_RegisterState::nativescript_handle); // Add this line
	Godot::gdnative_terminate(o);
}

It appears this workaround can be added to user code to suppress the crash
extern "C" void GDN_EXPORT godot_gdnative_terminate(godot_gdnative_terminate_options * o)
{
	Godot::nativescript_terminate(godot::_RegisterState::nativescript_handle); // Add this line
	Godot::gdnative_terminate(o);
}

I can confirm that this issue is still present even in 3.5 beta 3. And I also confirm that your workaround works for me to suppress the crash.

Echoing this for 3.4.4, will occur even if get_tree isn't used, was encountering this issue on clean up of ImageTextures and Images generated from a GDNative plugin. Above work around has resolved the issue for me!

The issue still exists in Godot 3.5 paired with the 3.5-stable labeled commits of godot-cpp and godot-headers. Any call to get_tree causes the issue later on during exit. @colugomusic's workaround above (call to nativescript_terminate) has fixed the issue for me as well.
Not sure if this would help at all in tracking down this bug, but intentionally leaking any node that has a NativeScript attached to it also prevents the crash on exit.
Furthermore, the stack trace at the time of the crash varies based on other factors. In my case, it's narrowing down the issue to get_tree that led me to this issue report; not the stack trace above.

Possibly related to godotengine/godot-cpp#860 ?

authors: ArdaE IlyaStuurFedorov akien-mga and3rson colugomusic cromerc geekrelief polyrain sisterhooddev


text:
Curve editor handles too small on Hi-DPI displays

Godot version
v3.3.stable.mono.official
System information
Windows 10
Issue description
The curve editor handles are too small on Hi-DPI displays (see image below).
The Hi-DPI curve editor is shown on the top.
The normal DPI curve editor is shown on the bottom.

Steps to reproduce
Open Godot editor on a Hi-DPI display and try to edit a curve resource.
Minimal reproduction project
Curve Handle Scaling Bug.zip

If anyone wants to try their hand at fixing this, look at editor/plugins/curve_editor_plugin.cpp, find where the selection rectangles are drawn and where the intersection tests are done (the visual representation should match the points' "hitbox"), and multiply those values by EDSCALE like this:
// A size of 5 becomes:
Math::round(5 * EDSCALE);

To test the editor at different scales, open Editor > Editor Settings and set Interface > Editor > Display Scale to a larger value like 150% or 200%.

I've always wanted to contribute so I'll give it a shot.

Hey Calinou I have a question about this:

Multiply the rectangle sizes in both drawing and input by EDSCALE like this

// A size of 5 becomes:
Math::round(5 * EDSCALE);

Do I need to round every time I multiply by the editor scale? Some of the code in curve_editor_plugin.cpp has no rounding at all when multiplying by the editor scale.

Do I need to round every time I multiply by the editor scale? Some of the code in curve_editor_plugin.cpp has no rounding at all when multiplying by the editor scale.

It's best to round to make non-integer scale factors behave better, but it's not strictly required. When you don't round, the number will be truncated, which means 1.5 will become 1.0 instead of 2.0. In general, I find rounding up looks better than rounding down when dealing with hiDPI scaling.

authors: Atlinx Calinou


text:
HTTPClient SSL does not work

Operating system or device - Godot version:
Windows V2.03.stable
Issue description (what happened, and what was expected):
HTTPClient will crash if SSL is used
Steps to reproduce:
var http = HTTPClient.new()
http.connect("google.com,16325,true,true)
while( http.get_status()==HTTPClient.STATUS_CONNECTING or http.get_status()==HTTPClient.STATUS_RESOLVING):
http.poll()
Link to minimal example project (optional but very welcome):
** Solution I used to fix it ***
Version: Windows V2.1.alpha
Uncomment line 319 of SConstruct (I think it needs more work then this which is why I am not pushing it in a git push.) and then compile

Do you mean uncomment the line #		env.Append(CPPPATH=['#drivers/builtin_openssl2'])?

Yes that is the line.

That's weird as openssl is builtin by default on Windows.
@punto- @vnen Seems like it could be another issue related to splitting the drivers into their own environment.

Now that I looked at this better, seems the same as #2157 and I thought this was fixed already, Isn't the asset lib is using SSL?

I tested this and it's not an issue with the drivers environment in SCons. This does not crash for me, but it hangs forever in CONNECTING status. If I use the proper HTTPS port (443) then it fails with the same console error that comes from the Asset Library: Some I/O error occurred. The OpenSSL error queue may contain more information on the error.

We just added SNI support, maybe this fixes the issue?

I can confirm that compiling with the latest code has fixed the issue.

hooray \o/
On Fri, Jul 1, 2016 at 7:57 PM, Catprog notifications@github.com wrote:

Closed #5154 https://github.com/godotengine/godot/issues/5154.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/5154#event-711027492, or mute
the thread
https://github.com/notifications/unsubscribe/AF-Z2xdkzKoAQnPRWjezrRUoKXW4b-mfks5qRZtFgaJpZM4IzfS5
.

authors: Catprog akien-mga reduz vnen


text:
Visual Script deletes disconnected node when deleting previously connected node

Godot version
Godot_v3.4.4-stable_x11.64
System information
Linux, Ubuntu 20.04 LTS, NVIDIA GTX 1650 Super, GLES3
Issue description
I have tried VisualScript for first time to check if it is any useful, and I found several bugs during my fooling around. This is one of the bugs I found. When I add _physics_process function by overriding it, then connect it with some other node, then disconnect it from the other node, then when I delete _physics_process then also the previously connected node disappears. There is no crash though, only that the nodes disappear without any warning.
Steps to reproduce

Create new project (OpenGL ES 3.0)
Click 3D Scene to create Spatial node
Add CSGBox as a child to Spatial node
Attach new VisualScript CSGBox.vs to the box
In visual editor click on Functions: override an existing built-in function
Choose Physics Process(float)
Right click on the plane and search for: Construct Vector 3XYZ and add it
Connect _physics_process delta with x of Construct Vector3
Disconnect _physics_process delta from x of Construct Vector3
Right click to _physics_process function in Members tool and choose Delete selected
The node "Construct Vector3" disappears together with _physics_process function
This is a bug!

You can at least CTRL+Z to restore previous state. Add any other node and delete _physics_process, it deletes all of them...
Minimal reproduction project
No response

VisualScript is buggy and probably should not be used by beginners. The problem is that every node is assigned to a function (or default function if there is not a function yet) and when you add more than one function the hell might break loose. If you connect a node that is or has been already connected to another function or some of it's nodes to the new function, it will try to do rescan and reassign nodes and connections from one function to another, but in some cases it steals new function's nodes (including it's own)  and try to assign it to old function. It might end up acting weird (worse as you can save it) or even crash (better scenario). Sometimes even newly added node is silently added to some function that already exists - problem if you have more than one in there. The problem is whole design of the Visual Script - there should not be "functions" with lists of theirs nodes and their nodes's connection, it should be viewed as a one graph and during compilation it should find all nodes that are actually a function and prepare a subgraph of nodes that should be called. So from one graph, there should be several subprograms. It would mean to refactor the code or even rewrite. It would move the complexity from the editor (terrible and buggy _move_nodes_with_rescan function that is the cause of most evil...) into script implementation - there might be even more code, but less convoluted and easier to read than the "hotfix" in the editor. I personally do not recommend adding Visual Script to Godot 4 until this is resolved.


text:
Error when using macros in shaders.

Godot version
4.0 alpha 13
System information
GNU/Linux Pop Os 20.04 GPU: Nvidia GeForce GTX 1070ti.
Issue description
The shader editor throws an error if I use a macros multiple times in one line of code.
No work

Work

Steps to reproduce
Define a macros and try to use it multiple times in one line of code.
Minimal reproduction project
No response

cc @Chaosus

Can confirm, one of the culprits might be this in expand_macros():
		// Remove expanded macro and recursively replace remaining.
		p_defines.remove_at(i);

The loop should try to expand macros until it no longer finds anything to expand and it naturally should not remove any defines during that loop. Looks like this regression happened when the regex was replaced with normal string logic. The whole expansion code feels unnecessarily complex too, I should have some free time to check this out, unless Chaosus wants to try.

I have the same problem. What should I do other than waiting someone to fix the bug?


text:
Editor freezes when creating a new project after moving Godot to the second screen

Tested versions
4.2.1 stable official
System information
Windows 10, NVidia GeForce GTX 1650 Ti, apparently OpenGL
Issue description
When creating a new project, the editor window freezes:

There is nothing of note in the console log, from what I can tell; the first two warnings are because I'm using the NuGet version, where the EXE filename isn't case-matching.
WARNING: Case mismatch opening requested file 'godot_v4.2.1-stable_win64.exe', stored as 'Godot_v4.2.1-stable_win64.exe.
     at: open_internal (drivers/windows/file_access_windows.cpp:132)
WARNING: Case mismatch opening requested file 'godot_v4.2.1-stable_win64.exe', stored as 'Godot_v4.2.1-stable_win64.exe.
     at: open_internal (drivers/windows/file_access_windows.cpp:132)
Godot Engine v4.2.1.stable.official.b09f793f5 - https://godotengine.org
OpenGL API 3.3.0 NVIDIA 532.09 - Compatibility - Using Device: NVIDIA - NVIDIA GeForce GTX 1650 Ti

Project is missing: c:/temp/audiotest/project.godot

Steps to reproduce

Set up your laptop with an external monitor, and Windows set to "Extend display"
Open Godot
Move Godot to the monitor screen
Click the new project button
Wait. Forever.

Note that creating a project on the first/default (laptop/internal) screen works fine.
Minimal reproduction project (MRP)
Not applicable.

Related to https://github.com/godotengine/godot/issues/74261.

Can you reproduce this if you force Godot to start on integrated graphics? This is likely a NVIDIA Optimus issue.

Can you reproduce this if you force Godot to start on integrated graphics? This is likely a NVIDIA Optimus issue.

Yes. I followed these instructions, and added every instance of Godot to use the integrated graphics driver. (The actual Godot .exe, which is 100MB+, as well as the Chocolatey wrapper EXE, and the godot console EXE).

This is replicable on a desktop 4090 with the latest NVIDIA 546.33 studio drivers and is not limited to a New Project. It will trigger on any action that tries to generate a pop-up element after moving the Project Manager window onto a second screen and even when both monitors are set to the same resolution and orientation.
Works

Mousing over the Asset Library Projects tab or any Project or Button (causing them to partial highlight).
Selecting a Project (causing a full highlight).
Switching between Projects and Asset Library Projects tabs.

Crashes

New, Import, Scan, or About (causes a pop-up window).
[en] English, or Sort (causes a dropdown style pop-up).

Once you open a window on your main monitor, you can drag it over to the new monitor without issue. Any of the above crash inducing functionalities (such as the Version Control Metadata dropdown menu within New Project) will work on your main monitor but crash from the second. The same principles will still apply when you load up a Project. One thing that causes a crash there is mousing over any resource, which causes a tooltip to pop up, which will crash Godot if it's in the second monitor. Enabling Single Window Mode or, conversely, disabling Multi Window Mode will fully protect Godot; you can move the Project window onto either monitor and everything works fine in either. However, the Project Manager window can't be protected in this way and will always crash.

Some people have had a similar freeze on some mobile devices that might be related

@Ruruie-FGSC thanks for the detailed description of what works and what doesn't!
The other work-around is simply not to do anything with Godot until you get your project loaded.

Recently discovered this could be renderer dependent.
The editor does not crash on Forward+ but will on Compatibility.
Project List seems to always be in Compatibility renderer however.


text:
Label fonts don't change to 1px as shown in the setting text box when font size is enabled

Tested versions
4.3 dev 6
System information
Godot v4.3.dev6 - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 970 (NVIDIA; 31.0.15.3623) - Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (8 Threads)
Issue description
If you turn on font size for the font used in a label, the setting for this says the font should be 1px in size, but it doesn't change.
If you use the up/down button, or type a value in the size field, it changes, but it should immediately change to match the value shown.
It should either immediately change the font to 1px high, or the setting textbox should change to match the default font size (16px)
Steps to reproduce
Create a label node
Add some text to it in the text setting
Under "Theme Overrides" -> "Font size", turn on the setting. You will see that the font size should be 1px, but the text in your game window stays the same.
Change 1px value and note that the displayed text then changes
Minimal reproduction project (MRP)
FontTest.zip

Seems like it's the issue with displayed default value. By default, it actually has font size set to 0, but property inspector think it's 1, since property hint sets 1-256 range for it.

authors: balloonpopper bruvzg


text:
ResourceLoader.CACHE_MODE_REPLACE does not work

Tested versions
Godot Engine v4.3.dev6.official.89850d553
System information
Windows 11, Vulkan API 1.3.205 - Forward+ - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce RTX 3060 Ti
Issue description
Load a resource, then modify this resouce, then load the resource again with ResourceLoader.load(path, "", ResourceLoader.CACHE_MODE_REPLACE), it returns the same resource as before.
func _ready() -> void:
	var path = "res://test.txt"
	var file = FileAccess.open(path, FileAccess.WRITE)
	file.store_string("00000000")
	file.flush()

	var mt = load(path) as MyTxt # MyTxt is a custom Resource loaded by a custom ResourceFormatLoader
	printt("before", mt, mt.content)

	file.store_string("yyyyyyyyyyyyyyy")
	file.flush()

	var mt2 = ResourceLoader.load(path, "", ResourceLoader.CACHE_MODE_REPLACE)
	printt("after using replace", mt2, mt2.content)

	var mt3 = ResourceLoader.load(path, "", ResourceLoader.CACHE_MODE_IGNORE)
	printt("after using ignore", mt3, mt3.content)

	print()
	print("Another case load an image...")

	var icon = load("res://icon.svg")
	printt("icon before", icon)
	var icon2 = ResourceLoader.load("res://icon.svg", "", ResourceLoader.CACHE_MODE_REPLACE)
	printt("icon after replace", icon2)
	var icon3 = ResourceLoader.load("res://icon.svg", "", ResourceLoader.CACHE_MODE_IGNORE)
	printt("icon after ignore", icon3)

output：
before	<Resource#-9223372008383838972>	00000000
after using replace	<Resource#-9223372008383838972>	00000000
after using ignore	<Resource#-9223372008115403521>	00000000yyyyyyyyyyyyyyy

Another case load an image...
icon before	<CompressedTexture2D#-9223372007981185787>
icon after replace	<CompressedTexture2D#-9223372007981185787>
icon after ignore	<CompressedTexture2D#-9223372007461092088>

I thinkmt2 and mt should be two different Object, and  icon2 and icon should be two different Object. Am I correct?
Steps to reproduce

open MRP
run project.

Minimal reproduction project (MRP)
test_resouce_load.zip

Reading the doc, https://docs.godotengine.org/en/latest/classes/class_resourceloader.html#enum-resourceloader-cachemode
Those already in the cache, as long as the loaded and cached types match, have their data refreshed from storage into the already existing instances.

It looks like CACHE_MODE_REPLACE should load the newer one because it's content is changed.

Do you mean that the object id won't change even though its' content has been changed? If so, I think it's fine that the object id dose not change. But, yes, the content has been changed so that we expect the Resource's raw content will be refreshed from storage.

@jsjtxietian Do you mean that the object id won't change even though its' content has been changed?

Yes but I'm only guessing from what the doc said.

authors: jinyangcruise jsjtxietian


text:
[4.3] Web Export not working via command line

Tested versions
4.3 Stable
System information
Windows 11
Issue description
I have tried to export my project to Windows & Web via command line (both locally and via GitHub actions using ubuntu).
The result is a working Windows export and a broken ZIP file for Web.
Steps to reproduce

Create new Project
Export > Manage Export Templates > download 4.3 templates
"Project > Export > Add..." Web export
Name it Web
Save everything
run /path/to/your/Godot_v4.3-stable_win64_console.exe --headless --verbose --export-release "Web" ./HTML5.zip --path "./"
Try to open resulting ZIP file
Message pops up telling you the zip file is invalid

I also tried different parameters, like running it in editor instead of headless mode or using export-debug or no path. All the same result
Note that exporting via Export in editor works fine!
Minimal reproduction project (MRP)
project.zip

$ /c/Programme/Godot/Godot_v4.3-stable_win64.exe --headless --verbose --export-release "Web" ./HTML5.zip --path "./" --preset "Web"
Godot Engine v4.3.stable.official.77dcf97d8 - https://godotengine.org
TextServer: Added interface "Dummy"
TextServer: Added interface "ICU / HarfBuzz / Graphite (Built-in)"
Using "default" pen tablet driver...

TextServer: Primary interface set to: "ICU / HarfBuzz / Graphite (Built-in)".
CORE API HASH: 966092234
EDITOR API HASH: 444927587
EditorSettings: Load OK!
EditorTheme: Generating new theme for the config '66886095'.
EditorTheme: Generating new icons.
EditorTheme: Generating new fonts.
EditorTheme: Generating new styles.
MbedTLS: Some X509 certificates could not be parsed (1 certificates skipped).
Loaded system CA certificates
EditorSettings: Save OK!
reimport: begin: (Re)Importing Assets steps: 3
        reimport: step 0: HTML5.apple-touch-icon.png
EditorFileSystem: Importing file: res://HTML5.apple-touch-icon.png
EditorFileSystem: Importing file: res://HTML5.icon.png
EditorFileSystem: Importing file: res://HTML5.png
        reimport: step 2: HTML5.png
EditorFileSystem: "res://HTML5.icon.png" import took 21 ms.
EditorFileSystem: "res://HTML5.apple-touch-icon.png" import took 24 ms.
EditorFileSystem: "res://HTML5.png" import took 84 ms.
reimport: end
savepack: begin: Packing steps: 102
        savepack: step 2: Storing File: res://.godot/imported/HTML5.apple-touch-icon.png-d6a7cfa7edd5c590291cda2a3af5295b.ctex
        savepack: step 2: Storing File: res://HTML5.apple-touch-icon.png.import
        savepack: step 22: Storing File: res://.godot/imported/HTML5.icon.png-84ee77950e212461b16466401620ed79.ctex
        savepack: step 22: Storing File: res://HTML5.icon.png.import
        savepack: step 42: Storing File: res://.godot/imported/HTML5.png-9554342e46048faa4bfd08e7976a82e1.ctex
        savepack: step 42: Storing File: res://HTML5.png.import
        savepack: step 62: Storing File: res://.godot/imported/icon.svg-218a8f2b3041327d8a5756f3a245f83b.ctex
        savepack: step 62: Storing File: res://icon.svg.import
        savepack: step 82: Storing File: res://.godot/exported/133200997/export-362256a061aa8890e9a1e558b11e5ec3-node_2d.scn
        savepack: step 82: Storing File: res://node_2d.tscn.remap
        savepack: step 82: Storing File: res://.godot/global_script_class_cache.cfg
        savepack: step 82: Storing File: res://icon.svg
        savepack: step 82: Storing File: res://.godot/uid_cache.bin
        savepack: step 82: Storing File: res://project.binary
savepack: end
EditorSettings: Save OK!
XR: Clearing primary interface
XR: Removed interface "Native mobile"
XR: Removed interface "OpenXR"
Orphan StringName: Node (static: 4, total: 5)
StringName: 1 unclaimed string names at exit.

just in case someone needs to see the logs

Can confirm:

Log:
godot.log

Does it work if you use HTML5.zip instead of ./HTML5.zip on the command line?

That doesn't work either
Am Fr., 8. Nov. 2024 um 19:57 Uhr schrieb Hugo Locurcio <
@.***>:

Does it work if you use HTML5.zip instead of ./HTML5.zip on the command
line?
—
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/97841#issuecomment-2465542677,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AATUYL2FP47FHTG7XW7D2KDZ7UCPVAVCNFSM6AAAAABPNGWK62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRVGU2DENRXG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

authors: Calinou Swarkin nyrrrr


text:
Area2D get_audio_bus and set_audio_bus renamed to get_audio_bus_name and set_audio_bus_name

This pull request refers to the following issue:
https://github.com/godotengine/godot/issues/11109
I've basically renamed the functions and also updated the docs regarging those.

Thanks for contributing! Please squash commits together. (PR workflow)

Okay done @Noshyaar

authors: Noshyaar paezao


text:
Fixed crash if convex has 0 vertices

fixes #21532

Thanks!

Cherry-picked for 3.0.7.

authors: AndreaCatania akien-mga


text:
Exported script properties and sub-resource scripts will now be properly treated as Scripts

…and will include the property name in the path if appropriate
This is my second attempt at solving this, and what I feel is a much better attempt than #30272 was.
This could still be a bit better (see my review comments below; plus the code could maybe be a tiny bit tidier, but I'm not sure how I'd go about it), but it is in a state that I'm happy with, and in a state that solves the issue at hand.

By the way, I should mention that even with this change, you still have to instantiate the scripts using some_script_var.new() or the like, much like you do when a exported property is a PackedScene -- it doesn't instantiate the script automatically like it does with an object's script property. However, static functions in the script are callable without instantiating it. So perhaps this could have some use in that regard?
I don't quite know how I would deal with this, but I don't know if I need to either.

Whenever someone gets to this PR, please let me know if I should make a proposal over at the godot-proposals repo. I've asked about what to do with PRs like this one over at https://github.com/godotengine/godot-proposals/issues/10#issuecomment-528075779, seeing as how it could be considered both a bugfix and an enhancement, each of which entails different prerequisites.

@LikeLakers2 Is this still desired? If so, it needs to be rebased on the latest master branch.

@aaronfranke I have no desire for it, personally -- and anyways, my PR comments never got a response like I needed. So I won't really be updating this PR. Should I close?

Also: If someone else wants to implement this PR, they are free to base it off of this PR -- though they should check out the PR comments above to see what I was stuck on.


text:
Prevent joypad button input dropdown going out of dialog

Fixes #37096
Prevent Joypad button name going outside dialog when editing button index for a device in Project settings.

Thanks!

Cherry-picked for 3.2.2.

authors: akien-mga alvaroHernandez


text:
[HTML5] Fix input not working when buffered.

After input buffering was reworked, input accumulation is now handled outside of OS, and the JavaScript plaform never implemented that.
Additionally, the JavaScript platform is quite obnoxious about calling specific APIs outside specific user triggered events.
This commit adds event flushing during the main iteration, and forces it during keydown/keyup/mousedown/mouseup/touchstart/touchend/touchcanel events (effectively only accumulating only "move" events).
Fixes #52468.
3.x version:  #52603

Would it make sense to do this only in process_events() and additionally add a conditional that does this inside input->parse_input_event()? Or add a setting to input like "flush after every event" that is enabled for JS, and then input->parse_input_event() flushes on each call?
Reason being
1.) this seems messy to have in 3 places that generate input events,
2.) this seeming error prone if we add more places that generate input events, because the implementer always needs to remember to also add the flush.

Or add a setting to input like "flush after every event" that is enabled for JS, and then input->parse_input_event() flushes on each call?

The main benefit from accumulation is in the handling of move and drag events. Which can be fired very rapidly.
I understand having the flush in the callbacks is a bit messy, but it's unlikely we'd add more events of that kind, because those really are the only relevant actions. I.e. we don't want to flush on every event, we only want to flush on clicks/press so we can interact with the APIs that requires direct user input.

authors: Faless mhilbrunner


text:
AnimationTree: New "Phase" Node

Phase node allows for the use of connected animation player nodes as a normalized seek (0.0->1.0) where you describe where in the animation you want to be. It will use the longest time of all connected animations to determine the phase scale.
This can be useful in circumstances where the user wants to treat an animation as it's own blend space, where the beginning and end of the animation represent a blend between states.
In the below video, I'm using hand tailored animation to represent a blend space between "full turn left" and "full turn right" of a snowboarder. When combined with other layers of animation, you could see that this would be quite powerful when programmatically animating a character. (The below image links to a youtube video.)

@Eoin-ONeill-Yokai Consider opening a proposal to help get this merged more easily :slightly_smiling_face:

I think it would be better to implement a Normalize option to SeekNode instead of implementing a new node. Having two nodes that do the same job makes it less maintainable.

I think it would be better to implement a Normalize and KeepFrame option to SeekNode instead of implementing a new node. Having two nodes that do the same job makes it less maintainable.

Believe it or not, I already have the ability to do this on my own Godot fork that I've held back on upstreaming for a few reasons -- one of which is just the lack wanting to propose it and face an uphill battle.
The second reason is much more reasonable issue -- having a freeze and normalize setting on the right-hand side inspector might technically work, but it won't be easily visible via the node section. I think the concept of phase makes a lot of sense in the world of DSP (You're not thinking in "time" but rather an abstract unit) so I think it actually makes sense to split these concepts as separate nodes. I do think that freezing a seek node should also be possible though! (And already have the work done if people are interested.)

@Eoin-ONeill-Yokai Consider opening a proposal to help get this merged more easily slightly_smiling_face
In particular, the proposal should explain how the current nodes don't suffice for your use case.

Yeah I can get around to that eventually. Since I already had the work of it done on my own branch, I figured just proposing an upstream solution would take less time overall as it's been relatively useful in my use case of needing to drive a full (arbitrary length) animation as a pseudo-blendspace.
With that being said, I think a much more important proposal to be made here would be a better system for allowing animation node additions without the need of hopping into C++. I was relatively surprised that I wasn't able to make my own module / plugin animation node and have that node show up in the "Add Node" menu in the editor. There probably should be a way to provide that within the current editor!
Additionally, perhaps it's just me, but compared to most modular systems, the input / output flow of the Animation tree seems like it might be backwards. Time should be input on the left side, and mesh data should be output on the right side.

I'm having trouble approving this phase node pull request.

There is no proposal. You have written more words explaining the proposal in your last comment, but you haven't filled in the template.
One of the animation maintainers proposed a suggestion which did not get a design review.

Normalize and KeepFrame option to SeekNode instead of implementing a new node. Having two nodes that do the same job makes it less maintainable. But, depending on the way of the KeepFrame function is implemented (Set delta to 0? or Always Seek? or Something), it might make sense to implement this as a separate Node. In that case, I think it should add a Normalize or not option to both Seek and Phase nodes to avoid confusion caused by different values in two Nodes that do similar work.

Unknown interactions with TimeScale and other Nodes
Unknown interactions with root scale

I rather agree with the implementation of this node, but I think it needs to at least match the behavior of NodeSeek. As I said above, it's confusing that this node is the only one that is normalized.
I'm not too worried about TimeScale, NodeSeek's behavior ignores TimeScale and other Nodes in the first place. As long as this NodePhase behaves the same way, I don't see a problem.
I think NodePhase allows the user to ignore the AnimationTree process and allow the animation to proceed as desired. This is also possible with Seek, but when you loop, i.e. when you go from 1 to 0, the root motion will play backwards. To solve this, for example, we need to allow a value greater than 1 and perform a mod calculation... or do something.
We also need to consider that always stopping means that there is always a possibility that the action of the stop frame key will be played. For example, the sound effect may continue to play every frame.

@fire @Calinou @TakageItLab I've gone ahead and made a godot proposal to discuss this current implementation and provide more details on why this should be merged.
Truth be told, I would be perfectly happy to keep these types of modifications to my own C++ module (like I do with some other tasks and custom nodes) but this particular type of modification did not seem easily achievable via either C++ module or GDScript due to how Add Node is implemented in the AnimationNodeTreeEditor where it won't automatically register subclasses of AnimationNode as valid nodes for the tree. See godotengine/godot-proposals#4077 for more details and discussion.

I know this is useful, but I think two modifications are needed.

Currently, this implementation achieves stopping the animation by always doing a Seek. However, always Seek is problematic because it fires events for the keyframes after Seek. So it needs to set Delta to 0 to stop the animation, just like TimeScale does.

Avoid time normalization. It will create an inconsistency with SeekNode, which has a similar role. Or, implement an option to normalize or not normalize, and then implement the same option for SeekNode.

I was thinking about implementing this, but it seems to me that we need to allow optional animation lengths to be set in the NodePhase itself, since in blended animations they do not always have to be the same length.

I see. Currently I'm just recursively going through the tree and finding the longest animation currently attached as the basis for the phase. I suppose we could modify this so that the time is manually set by the user instead. My thought process when making it was to make it as convenient to switch in / out new animations as possible while also supporting smaller "noise" channels that allow for more procedurals (for example, a breathing layer, a shakiness layer for hand movement, etc.)
I think we could actually program that part of the logic in the GUI side though -- where you could click a button when the phase node is selected to get the longest animation length down the chain of connected animation nodes. That might be a nice middle ground here.

Any update on this?

authors: Calinou Eoin-ONeill-Yokai TokageItLab eddieataberk fire


text:
Re-add AnimationNodeStateMachine::end_node for root state machine

Fix #63660
EndState is required for OneShot as commented here https://github.com/godotengine/godot/issues/63660#issuecomment-1201475180

Some further notes on other issues I have though and may be worth addressing down the line: based on some discussion in the RocketChat, I personally feel it would make sense if using the exit node on actual root state machine made the state machine loop rather than simply end. This could have some actual utility since there's no immediate way to return the start node. Secondly, it would be also nice to clean up some of the console errors when attempting to make connections to and from start/end nodes.

authors: SaracenOne guilhermefelipecgs


text:
Fix highlight current script when script temperature is disabled

Fix highlight current script, not updating when script temperature is disabled.

Moved script temperature logic into if statement.

What I had in mind was more:
 	bool script_temperature_enabled = EditorSettings::get_singleton()->get("text_editor/script_temperature_enabled");
 	bool highlight_current = EditorSettings::get_singleton()->get("text_editor/highlight_current_script");

 	if (script_temperature_enabled) {

 	 	int hist_size = EditorSettings::get_singleton()->get("text_editor/script_temperature_history_size");
 	 	Color hot_color=EditorSettings::get_singleton()->get("text_editor/script_temperature_hot_color");
 	 	Color cold_color=EditorSettings::get_singleton()->get("text_editor/script_temperature_cold_color");

 	 	for(int i=0;i<script_list->get_item_count();i++) {

 		 	int c = script_list->get_item_metadata(i);
 	 		Node *n = tab_container->get_child(c);
 	 		if (!n)
 		 		continue;

 		 	script_list->set_item_custom_bg_color(i,Color(0,0,0,0));
			if (!n->has_meta("__editor_pass")) {
				continue;
			}

			int pass=n->get_meta("__editor_pass");
			int h = edit_pass - pass;
			if (h>hist_size) {
				continue;
			}
			int non_zero_hist_size = ( hist_size == 0 ) ? 1 : hist_size;
			float v = Math::ease((edit_pass-pass)/float(non_zero_hist_size),0.4);

			script_list->set_item_custom_bg_color(i,hot_color.linear_interpolate(cold_color,v));
	}

	if (highlight_current) {
		// TODO: here comes some logic to get current tab ID from tab_container->get_current_tab()
		script_list->set_item_custom_bg_color(i, EditorSettings::get_singleton()->get("text_editor/current_script_background_color"));
	}

i.e. don't iterate and do operations on all tabs when highlight_current alone only means that you need to change one tab. Of course if there's no simple way to do my TODO without iterating over all items, my solution is not that good.

You need to iterate over the items to clear the colours first ( this also has a nice side effect of fixing the colours remaining after disabling script_temperatures), else everything will end up being coloured.


text:
Fix crash caused by non-deferred signal connection for _property_keyed

This is likely an oversight since we're also doing this for _property_deleted .
I might recommend we add a DEV_ASSERT to object.cpp::1800 so that we can track these types of rug-pulling situations. I'm not confident that the story ends here as I noticed that a backtrace when using breakpoints for that error message comes from editor_node.cpp:2302 . I missed capturing the entire call stack, but I can try again later to see if I can get a sense of whether there's anything dangerous going on.
Anyway, having tested with this fix, there hasn't been any crashes and I haven't noticed any regressions. I'll get the user who posted to test out the changes on his end if he can.
Closes #69829

As I recall, the problem was that key inserts were not updated until redraw, not track inserts, so I remember fixing this before. I'll take a look at it later.

Superseded by #70170

authors: Eoin-ONeill-Yokai TokageItLab


text:
[3.x] Update the format for the app version code and name

Differentiate the status code for the alpha and dev versions.
main version

Thanks!


text:
Add external texture support

Starting a draft to discuss the proper way to integrate support for external texture in Godot 4.x.
This is feature that's forward-ported from Godot 3.x and is key to enable support for texture that can be painted by the target platform (see the original PR for target use-cases).
As mentioned in https://github.com/godotengine/godot/pull/36342#pullrequestreview-369375100, this was punted for the 4.x release due to GLES reimplementation and the need to figure out how this applies to Vulkan.
This draft aims to restart the conversation in order to properly integrate it in Godot 4.x

cc @maunvz

@paddy-exe FYI, this is required to support ARCore in Godot

How does this relate to textures created via TextureStorage::texture_create_external() (in the OpenGL renderer)? That function is being used for OpenXR (on OpenGL) and WebXR.
Or, if this doesn't relate to that (like, if it's a totally different thing) then we should probably rename one of them, because having two unrelated types of textures both called "external" is going to be confusing :-)

How does this relate to textures created via TextureStorage::texture_create_external() (in the OpenGL renderer)? That function is being used for OpenXR (on OpenGL) and WebXR.
Or, if this doesn't relate to that (like, if it's a totally different thing) then we should probably rename one of them, because having two unrelated types of textures both called "external" is going to be confusing :-)

@dsnopek they're indeed different things; see this comment that goes on the difference between the two: https://github.com/godotengine/godot/issues/65778#issuecomment-1249351066
Renaming is made complex by the fact the one I'm referring to is part of the OpenGL spec, so arguably the current Godot one should be renamed to be consistent with external references, but I don't have a strong preferences either way so long as it's clear which one we're referring to.

As mentioned in this StackOverlfow thread, this may be supported in Vulkan using the VK_ANDROID_external_memory_android_hardware_buffer extension.

they're indeed different things; see this comment that goes on the difference between the two: #65778 (comment)
Renaming is made complex by the fact the one I'm referring to is part of the OpenGL spec, so arguably the current Godot one should be renamed to be consistent with external references, but I don't have a strong preferences either way so long as it's clear which one we're referring to.

I think it'd be fine to rename the existing TextureStorage::texture_create_external() to something else - it's not exposed publicly anywhere, and only used in those two places. I don't have any brilliant naming ideas, though. :-)
Maybe:

TextureStorage::texture_create_foreign()
TextureStorage::texture_create_reference() -- the idea being it "references" a texture created elsewhere
TextureStorage::texture_create_remote()
TextureStorage::texture_create_third_party()
TextureStorage::texture_create_independent()

Naming is hard :-)

cc @clayjohn , you should have a look at this too.

Is this android specific or will it work on iOS as well?

Is this android specific or will it work on iOS as well?

It's not Android specific in theory, but it uses OpenGLES and Vulkan extensions which iOS doesn't (officially) support, so there would need to be investigation on whether this is available to iOS through the available compatibility APIs.
cc @BastiaanOlij @clayjohn

Superseded by https://github.com/godotengine/godot/pull/96982

authors: BastiaanOlij dsnopek m4gr3d pritish-thub


text:
GDScript: Use autoload singleton name in GDScriptDocGen

Closes godotengine/godot-proposals#8441.

You can't use the autoload singleton name as a class name, so I think it's safe to use the autoload name instead of the script path in the docs. If the autoload script also has a global name, then it will be used first.

test-autoload-doc.zip

Thanks!

authors: akien-mga dalexeev


text:
Fix crash on changing resource type of dictionary new key/value while editing the resource.

Fixes #88286

Thanks!

authors: ajreckof akien-mga


text:
Fix folder color not cleared for removed subfolders

Fixes #90808

Thanks!

authors: akien-mga timothyqiu


text:
GDScript: Implement get_dependencies() (reverted)

The parser and analyzer now track the dependencies of the script and return the list when the resource loader ask for them.
What is considered a dependency:

Any preload() call.
The base script this one extends.
Any identifier, including types, that refers to global scripts.
Any autoload singleton reference.

Fix #90643
P.S.: Initially I included the @icon path as a dependency, but I removed it since it's only relevant in the editor context. I don't think it's even accessible in a release build, so it shouldn't impact exporting the project.

Reverted by #91908 to solve #91726.
#90643 was thus reopened.

authors: akien-mga vnen


text:
Fix project name cleared when browsing path

Fixes #95038

Thanks!

authors: KoBeWi akien-mga


text:
Prevent crash after removing GraphEdit's connection layer

Closes #96289.
Adds a descriptive warning when you accidentally remove the connection layer plus some checks everywhere a crash could occur (not ideal, but at least it's safe).

Thanks!

Every time I close the editor (with opened project) I see following warning:
WARNING: GraphEdit's connection_layer removed. This should not be done. If you like to remove all GraphElements from a GraphEdit node, do not simply remove all non-internal children but check their type since the connection layer has to be kept non-internal due to technical reasons.
     at: remove_child_notify (scene/gui/graph_edit.cpp:656)

Needs to be cherry-picked together with #96309.

authors: Geometror akien-mga dustdfg


text:
Add get_connection_count method to GraphEdit

Closes: godot-proposals/issues/10942
Adds a method to GraphEdit to get the number of connections to a given node and port (get_connection_count(to_node,to_port)).
With this we can easily limit the number of connections using the condition:
if get_connection_count(to_node,to_port)<1:
	connect_node(from_node,from_port,to_node,to_port)

This is my first PR for Godot and I'm also pretty new to Git, if there's anything wrong let me know and I'll try to fix it.
Test project:
graphedit_test_func.zip

Sorry, I posted two commits at once, is there any way to fix this? 😅

You need to squash your commits. Here is a Godot guide about it Guide.

It should be called get_connections_count().

It should be get_connection_count in fact, to follow English grammar

It should be get_connection_count in fact, to follow English grammar

Done!

I noticed one error when checking CI, should I worry about it?

I noticed one error when checking CI, should I worry about it?

The CI error is here: https://github.com/godotengine/godot/actions/runs/11797387846/job/32861548434?pr=99045
The problem is that you added the XML template for the documentation of the new method manually, and it's not in the right place. Methods need to be ordered alphabetically so it needs to be moved further up.
Or you can use <path/to/godot> --doctool to do it.

I have prepared a fix, but git gives me an error, I also merged the latest Master branch with mine, what could be the problem?


text:
🐛 [Bug]: OTeL duplicate and wrong counter metrics are generated infinitely

Bug Description
I have raised a bug  issue in opentelemetry-go SDK repository.
When using fiber to manually reporting request count with delta temporality, the server will keep reporting wrong attributes value and wrong datapoint size infinitely.

demo code

While using go http library or something else, everything work as expected so I got the right request count.
How to Reproduce
See my demo repository:
https://github.com/oliverdding/otel-test
Start with:
docker compose up -d --build

Or you can run go cmd program manually with:
docker compose up -d otel-collector

Expected Behavior
There should be ten datapoints, with app_id from 1 to 10.
Fiber Version
v2.49.2
Code Snippet (optional)
package main

import (
	"context"
	"fmt"
	"math/rand"
	"net/http"
	"os"
	"time"

	"go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp"
	"go.opentelemetry.io/otel"
	"go.opentelemetry.io/otel/attribute"
	"go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc"
	"go.opentelemetry.io/otel/metric"
	sdkmetric "go.opentelemetry.io/otel/sdk/metric"
	"go.opentelemetry.io/otel/sdk/metric/metricdata"
	"go.opentelemetry.io/otel/sdk/resource"
	semconv "go.opentelemetry.io/otel/semconv/v1.18.0"
	"go.uber.org/zap"
	"go.uber.org/zap/zapcore"
)

var (
	logger *zap.Logger
)

func init() {
	var cfg zap.Config
	cfg = zap.NewDevelopmentConfig()

	// set time format
	cfg.EncoderConfig.EncodeTime = zapcore.TimeEncoderOfLayout(time.DateTime)
	// add color for console
	cfg.EncoderConfig.EncodeLevel = zapcore.CapitalColorLevelEncoder
	logger = zap.New(zapcore.NewCore(zapcore.NewConsoleEncoder(cfg.EncoderConfig), zapcore.NewMultiWriteSyncer(zapcore.AddSync(os.Stdout)), zapcore.DebugLevel))
}

func preferDeltaTemporalitySelector(kind sdkmetric.InstrumentKind) metricdata.Temporality {
	switch kind {
	case sdkmetric.InstrumentKindCounter,
		sdkmetric.InstrumentKindObservableCounter,
		sdkmetric.InstrumentKindHistogram:
		return metricdata.DeltaTemporality
	default:
		return metricdata.CumulativeTemporality
	}
}

func initProvider(ctx context.Context) func() {
	res, err := resource.New(ctx,
		resource.WithFromEnv(),
		resource.WithProcess(),
		resource.WithTelemetrySDK(),
		resource.WithHost(),
		resource.WithAttributes(
			semconv.ServiceName("client"),
			semconv.ServiceNamespace("demo"),
			semconv.ServiceVersion("0.1.0"),
		),
	)
	if err != nil {
		logger.Fatal("failed to create resource", zap.Error(err))
	}

	otelAgentAddr, ok := os.LookupEnv("OTEL_EXPORTER_OTLP_ENDPOINT")
	if !ok {
		otelAgentAddr = "127.0.0.1:4317"
	}
	metricExp, err := otlpmetricgrpc.New(
		ctx,
		otlpmetricgrpc.WithInsecure(),
		otlpmetricgrpc.WithEndpoint(otelAgentAddr),
		otlpmetricgrpc.WithCompressor("gzip"),
		otlpmetricgrpc.WithTemporalitySelector(preferDeltaTemporalitySelector),
	)

	meterProvider := sdkmetric.NewMeterProvider(
		sdkmetric.WithResource(res),
		sdkmetric.WithReader(
			sdkmetric.NewPeriodicReader(
				metricExp,
				sdkmetric.WithInterval(2*time.Second),
			),
		),
	)
	otel.SetMeterProvider(meterProvider)

	return func() {
		cxt, cancel := context.WithTimeout(ctx, time.Second)
		defer cancel()
		// pushes any last exports to the receiver
		if err := meterProvider.Shutdown(cxt); err != nil {
			otel.Handle(err)
		}
	}
}

var (
	rng       = rand.New(rand.NewSource(time.Now().UnixNano()))
	meter     metric.Meter
	appIDList = []string{"1024", "568", "106", "1025", "197"}
)

func main() {
	ctx := context.Background()
	otelShutdownHook := initProvider(ctx)
	defer otelShutdownHook()

	meter = otel.Meter("demo-server")

	requestLatency, _ := meter.Float64Histogram(
		"demo_client/request_latency",
		metric.WithDescription("The latency of requests processed"),
	)

	requestCount, _ := meter.Int64Counter(
		"demo_client/request_counts",
		metric.WithDescription("The number of requests processed"),
	)

	for {
		appID := appIDList[rng.Intn(len(appIDList))]
		startTime := time.Now()
		makeHelloRequest(ctx, appID)
		latencyMs := float64(time.Since(startTime)) / 1e6
		requestLatency.Record(ctx, latencyMs, metric.WithAttributes(attribute.String("interface", "hello"), attribute.String("app_id", appID)))
		requestCount.Add(ctx, 1, metric.WithAttributes(attribute.String("interface", "hello"), attribute.String("app_id", appID)))

		fmt.Printf("Latency: %.3fms\n", latencyMs)
		time.Sleep(time.Duration(1) * time.Second)

	}
}

func makeHelloRequest(ctx context.Context, appID string) {
	demoServerAddr, ok := os.LookupEnv("DEMO_SERVER_ENDPOINT")
	if !ok {
		demoServerAddr = "0.0.0.0:2333"
	}

	// Trace an HTTP client by wrapping the transport
	client := http.Client{
		Transport: otelhttp.NewTransport(http.DefaultTransport),
	}

	// Make sure we pass the context to the request to avoid broken traces.
	req, err := http.NewRequestWithContext(ctx, "GET", fmt.Sprintf("http://%s/hello/%s", demoServerAddr, appID), nil)
	if err != nil {
		logger.Fatal("failed to create request", zap.Error(err))
	}

	// All requests made with this client will create spans.
	res, err := client.Do(req)
	if err != nil {
		logger.Fatal("failed to execute request", zap.Error(err))
	}
	res.Body.Close()
}

Checklist:

[X] I agree to follow Fiber's Code of Conduct.
[X] I have checked for existing issues that describe my problem prior to opening this one.
[X] I understand that improperly formatted bug reports may be closed without explanation.

This is incorrect usage of Fiber.
See https://pkg.go.dev/github.com/gofiber/fiber/v2#Ctx.Params

Returned value is only valid within the handler. Do not store any references. Make copies or use the Immutable setting to use the value outside the Handler.

Can you share the line you are referring to?

Sorry I responded in bad issue 😉
See here https://github.com/open-telemetry/opentelemetry-go/issues/4563

Oh😢, it's my fault...
Thanks for pointing out

authors: ReneWerner87 oliverdding pellared

repo: gofiber/contrib


text:
Support NewHTTPService with Header

Support for adding headers while initialising HTTP client, as we want to use same header for all requests

Duplicate of #498

repo: gofr-dev/gofr


text:
Caching Hugo modules in ~/.cache/hugo/modules

I use Hugo modules all the time and it works great. However, one minor annoyance that I face is that it downloads the modules to /tmp/hugo_cache/modules. This means that I lose the cached modules after a reboot.
Would it be possible to have a configurable env var for specifying where Hugo caches its modules, and I mean modules alone. I tried changing HUGO_CACHE and it works but as it also caches build files, I don't want to use it as I want avoid too many writes to my HDD.

Never tried cofiguring cache, but have you tried this? Configure Caches
caches:
  modules:
    dir: :cacheDir/modules
    maxAge: -1

:cacheDir
This is the value of the cacheDir config option if set (can also be set via OS env variable HUGO_CACHEDIR). It will fall back to /opt/build/cache/hugo_cache/ on Netlify, or a hugo_cache directory below the OS temp dir for the others. This means that if you run your builds on Netlify, all caches configured with :cacheDir will be saved and restored on the next build. For other CI vendors, please read their documentation. For an CircleCI example, see this configuration.

@pamubay Thank you. I set this systemwide through:
export HUGO_CACHES_MODULES=$XDG_DATA_HOME/hugo"

authors: UtkarshVerma pamubay

repo: gohugoio/hugo


text:
Expand lookup order

Can't find a spot where the lookup order for cli and environment are, so added it here. Please fell free to deny this request or change it as you see fit.

 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.

We have moved the Hugo site source to its own repository, so we would appreciate if you could open this PR directly in hugoDocs:  https://github.com/gohugoio/hugoDocs/pulls
Also, if you consider the config directory, the lookup order for config is slightly more elaborated.

authors: CLAassistant KalleDK bep