text:
Godot 3 consume 4x more memory than Godot 2

Godot version:

Godot 3 beta 1
Godot 2.1.4

OS/device including version:
Windows 10 x64
GTX 960
16gb ram
Issue description:
Godot 3 consume 4x more memory than v2
Steps to reproduce:
Create empty scene, then export to Windows Desktop

Well, the code is bigger. So it's normal it consumes more memory...
But maybe there's a leak somewhere.

I have no idea how to debug what is using memory, is there any kind of
memory debugger?
On Tue, Dec 19, 2017 at 8:56 PM, Gilles Roudiere notifications@github.com
wrote:

Well, the code is bigger. So it's normal it consumes more memory...
But maybe there's a leak somewhere.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/14845#issuecomment-352922841,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z21NP1fmnevn2YGjCpCOXFMkgInevks5tCE06gaJpZM4RHpzH
.

I'd say, does it count how much memory is allocated on the GPU. All the effects buffers would take up a lot of memory. It be interesting to see if it gets less when you turn effects of in the project settings. I'll see if I can reproduce on my Windows machine.
All in all 126Mb is nothing in this day and age....

I'd say, does it count how much memory is allocated on the GPU?

No, the Windows task manager shows only the regular RAM there. The Fall Creators Update can show GPU memory but only in general, not per-process. I notice a 0.5 GB increase in the GPU memory usage when I open Godot.
I know Visual Studio has a heap profiler, but don't know how useful it is.

I can't really reproduce this on Linux/x86_64. Running a scene with just one node in it shows a peak memory use of 24MB:

The editor uses a little more ram, a little over 130MB:

Most of the RAM usage for the editor are:

Two static allocations of 16MB for the debugger interface used to communicate with the engine when you press the 'play' button in the editor.
11MB of RAM used to store the translations.
about 8MB used by the OpenGL shader cache (Not Godot code)
about 8MB used by bullet

In 3.0 the debug buffer size was dramatically increased to improve stability when debugging larger projects so this by itself already accounts for 1/3rd of the memory use increase. We also now use a nicer font which is larger, which accounts for quite a bit.
I'm not sure if this is really a problem all in all. Maybe we could shrink memory use a little bit but an exported game seems to not really use much more RAM than in 2.1

11MB of RAM used to store the translations.

Does this include all languages? Since a restart is needed to change translations, we could maybe avoid store them all and just keep the current language (+ EN used as fallback).

Using a recent master compiled with scons platform=windows uses 60mb RAM in project manager and 120mb RAM in a empty test project on Windows 7 x64.

On godot 3 master as of about 15 minutes ago, I get ~300MB in the project manager (and 260+MB of GPU memory usage). Detailed breakdown here.
On godot 2.14 (from the distro), I get ~50MB in the project manager (and ~37MB of GPU mem). Detailed breakdown here.

cppcheck identified two memory leaks.  I'm not sure if they're valid, someone else with more experience should probably check.
In os_iphone.cpp it's reporting a memory leak on new_ptr after line 591.
In memory.cpp it's reporting a memory leak on mem after line 98.
Hope that helps.

I think i figured out what's wrong with memory usage
Try to run the .exe multiple times, sometimes it takes 70mb, sometimes 130mb
Maybe something doesn't have time to be freed during initialization ?

Many memory leaks have been fixed since this issue was created. Can anyone reproduce high RAM usage on Godot 3.2.1 or 3.2.2beta2?
Note that Godot 4's RAM requirements will likely increase, in the interest of offering better performance (more things can be cached this way).

Closing per the above comment.

source: gharchive/issue

authors: BastiaanOlij Calinou Scellow Web-eWorks akien-mga firefly2442 groud hpvb mhilbrunner reduz vnen

license: MIT

license_type: permissive

license_source: github-api


text:
Crash when disconnecting signal

Godot version:
9a5950a
Issue description:
Clicked disconnect button on a signal.
Not terribly helpful, but maybe someone will of come across this as well.
Steps to reproduce:
N/A

Backtrace
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] /lib/x86_64-linux-gnu/libc.so.6(+0x354b0) [0x7f0cd42824b0] (??:0)
[2] Vector<TreeItem::Cell>::size() const (godot/core/vector.h:115)
[3] TreeItem::get_metadata(int) const (godot/scene/gui/tree.cpp:304 (discriminator 2))
[4] ConnectionsDock::_make_or_edit_connection() (godot/editor/connections_dialog.cpp:439 (discriminator 2))
[5] MethodBind0::call(Object*, Variant const**, int, Variant::CallError&) (godot/core/method_bind.gen.inc:56 (discriminator 4))
[6] Object::call(StringName const&, Variant const**, int, Variant::CallError&) (godot/core/object.cpp:914 (discriminator 1))
[7] Object::emit_signal(StringName const&, Variant const**, int) (godot/core/object.cpp:1195 (discriminator 1))
[8] Object::emit_signal(StringName const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&) (godot/core/object.cpp:1241)
[9] ConnectDialog::ok_pressed() (godot/editor/connections_dialog.cpp:109 (discriminator 2))
[10] AcceptDialog::_ok_pressed() (godot/scene/gui/dialogs.cpp:387)
[11] MethodBind0::call(Object*, Variant const**, int, Variant::CallError&) (godot/core/method_bind.gen.inc:56 (discriminator 4))
[12] Object::call(StringName const&, Variant const**, int, Variant::CallError&) (godot/core/object.cpp:914 (discriminator 1))
[13] Object::emit_signal(StringName const&, Variant const**, int) (godot/core/object.cpp:1195 (discriminator 1))
[14] Object::emit_signal(StringName const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&) (godot/core/object.cpp:1241)
[15] BaseButton::_gui_input(Ref<InputEvent>) (godot/scene/gui/base_button.cpp:139 (discriminator 2))
[16] MethodBind1<Ref<InputEvent> >::call(Object*, Variant const**, int, Variant::CallError&) (godot/core/method_bind.gen.inc:729 (discriminator 12))
[17] Object::call_multilevel(StringName const&, Variant const**, int) (godot/core/object.cpp:748 (discriminator 1))
[18] Object::call_multilevel(StringName const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&) (godot/core/object.cpp:855)
[19] Viewport::_gui_call_input(Control*, Ref<InputEvent> const&) (godot/scene/main/viewport.cpp:1391 (discriminator 2))
[20] Viewport::_gui_input_event(Ref<InputEvent>) (godot/scene/main/viewport.cpp:1741 (discriminator 3))
[21] Viewport::input(Ref<InputEvent> const&) (godot/scene/main/viewport.cpp:2388 (discriminator 2))
[22] Viewport::_vp_input(Ref<InputEvent> const&) (godot/scene/main/viewport.cpp:1217)
[23] MethodBind1<Ref<InputEvent> const&>::call(Object*, Variant const**, int, Variant::CallError&) (godot/core/method_bind.gen.inc:729 (discriminator 12))
[24] Object::call(StringName const&, Variant const**, int, Variant::CallError&) (godot/core/object.cpp:914 (discriminator 1))
[25] Object::call(StringName const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&) (godot/core/object.cpp:839)
[26] SceneTree::call_group_flags(unsigned int, StringName const&, StringName const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&) (godot/scene/main/scene_tree.cpp:251)
[27] SceneTree::input_event(Ref<InputEvent> const&) (godot/scene/main/scene_tree.cpp:407 (discriminator 6))
[28] InputDefault::_parse_input_event_impl(Ref<InputEvent> const&, bool) (godot/main/input_default.cpp:392)
[29] InputDefault::parse_input_event(Ref<InputEvent> const&) (godot/main/input_default.cpp:260)
[30] OS_X11::process_xevents() (godot/platform/x11/os_x11.cpp:1892 (discriminator 3))
[31] OS_X11::run() (godot/platform/x11/os_x11.cpp:2588)
[32] godot/bin/godot.x11.tools.64(main+0xd3) [0xf59439] (godot/platform/x11/godot_x11.cpp:56)
[33] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f0cd426d830] (??:0)
[34] godot/bin/godot.x11.tools.64(_start+0x29) [0xf59299] (??:?)
-- END OF BACKTRACE --

can't reproduce it with 0980991e6
maybe it requires more exact steps or sample project to reproduce.

Steps to reproduce would indeed be good.

Looks like the same access-after-free I was seeing when looking into #19001.
I think #20131 fixes this.

Assuming fixed by #20131.

authors: akien-mga ibrahn menip volzhs

repo: godotengine/godot


text:
Changing AnimationNodeAnimation.Animation results in crash, if the animation is dynamically added

Godot version:
master / 0ffec7daf
OS/device including version:
Manjaro Linux 17.1
Issue description:
If you add an anination to AnimationPlayer programatically then change Animation property of an AnimationNodeAnimation node contained in an associated AnimationTree, the game will crash if you attempt to play it using AnimationNodeOneShot with the following output:
Stacktrace:

/proc/self/maps:
400b5000-400c5000 rwxp 00000000 00:00 0
40434000-407fc000 rwxp 00000000 00:00 0
40e39000-40e49000 rwxp 00000000 00:00 0
41138000-41148000 rwxp 00000000 00:00 0
41809000-4180b000 r-xs 00000000 00:2d 192                                /tmp/.glDqt8YB (deleted)
41b8e000-41c2f000 rw-p 00000000 00:00 0
55809b885000-5580a0049000 r-xp 00000000 08:07 3151468                    /usr/bin/godot
5580a0249000-5580a034c000 r--p 047c4000 08:07 3151468                    /usr/bin/godot
5580a034c000-5580a0352000 rw-p 048c7000 08:07 3151468                    /usr/bin/godot
5580a0352000-5580a036a000 rw-p 00000000 00:00 0
5580a0a79000-5580af5da000 rw-p 00000000 00:00 0                          [heap]
7f3c24000000-7f3c24021000 rw-p 00000000 00:00 0
7f3c24021000-7f3c28000000 ---p 00000000 00:00 0
7f3c2c000000-7f3c2c270000 rw-p 00000000 00:00 0
7f3c2c270000-7f3c30000000 ---p 00000000 00:00 0
7f3c30000000-7f3c30060000 rw-p 00000000 00:00 0
7f3c30060000-7f3c34000000 ---p 00000000 00:00 0
7f3c34000000-7f3c3414f000 rw-p 00000000 00:00 0
7f3c3414f000-7f3c38000000 ---p 00000000 00:00 0
7f3c38000000-7f3c3804a000 rw-p 00000000 00:00 0
7f3c3804a000-7f3c3c000000 ---p 00000000 00:00 0
7f3c3c000000-7f3c3c021000 rw-p 00000000 00:00 0
7f3c3c021000-7f3c40000000 ---p 00000000 00:00 0
7f3c42c00000-7f3c42d00000 rw-p 00000000 00:00 0
7f3c42d49000-7f3c44d4a000 rw-p 00000000 00:00 0

Unhandled Exception:
System.NullReferenceException: Object reference not set to an instance of an object

Reopening as it seems the crash still happens, as per https://github.com/godotengine/godot/pull/20628#issuecomment-415945008.

I just checked my build today, and It turned out the relevant commit(f6c0a3f) was indeed missing. Sorry for the hassle!
I suppose I missed the conflict message when I tried to cherry pick the commit and assumed it was merged. Anyway, feel free to close this issue and I'll repoen if necessary later, after I'll be able to use the master branch again.

Finally, I managed to make my project properly build again with the latest master and I did another test of this issue.
Unfortunately, it seems to happen most of the times still(only rarely it worked without crashing but I haven't been able to reproduce it reliably yet).
This time, I double checked the changes made in f6c0a3f are included in my build. And the stacktrace shows it crashes at AnimationTree::_process_graph in the following line, apparently because it refers to a track with a wrong index (from the old animation):
if (track->type != a->track_get_type(i)) {

I can't reproduce this bug, sorry. Please make a small demo project.

Ok, then please feel free to close the issue.
For now, I can't even use the latest master any more due to some other issue. So, once I'll be able to use the latest master again and happen to revisit the animation part, I'll try to reproduce it and reopen the issue with an example project if needed.

Closing for now then.

authors: akien-mga mysticfall reduz


text:
Godot doesn't scale svg file when I using the image as icon via class_name

Godot version:
3.1 5738c92
OS/device including version:
Windows 10
Issue description:
When I create script with this lines
extends Character

class_name Enemy, "res://Characters/Enemy.svg"

I expect that Godot take Enemy.svg image, scale it and put to creating new node window, but it doesn't scale it and it looks terrible:

Probably Godot take svg parameters from import tab, but for me should import once again this file to e.g. 32px(I don't know how big is default size)

CC @willnationsdev

@akien-mga The default size is 16x16 I believe. I'm not sure what exactly the fix for this would be though. We'd have to somehow detect on import whether an icon was affiliated with a script class, and then enforce a 16x16 size in that case...or something? I don't know anything about the import process, nor who should be cc'd for assistance on that.

Also it is visible in Scene Dock.
When I change a canvas size in Inkscape to 16mm, then in File System dock svg files lost quality but as you can see in Scene dock this image have big resolution(in import i used scale=4)

Yeesh. Well, maybe it has something to do with the editor having different processes for using svg's at different scales (i.e. at which point in the process is it converting them to a rasterized format like png and using them)?

authors: akien-mga qarmin willnationsdev


text:
GI-Probe/Light Baking documentation lacks an important piece of info

The fact I didn't know about this from reading the documentation prevented the use of GI-probes in my game until just today.
The piece of info lacking in the docs. is this. That being that GI-probes and baked lighting will only work if the nodes are in the first level of the scene tree.
So for instance having Top Node > GI Probe will work, but having Top Node > Probes > GI Probe will not. I don't know if this is by design or if it can be treated like a bug, but I imagine it would throw a lot of people off if they like to categorize their nodes.

@Ace-Dragon Can you (or anyone else) still reproduce this bug in Godot 3.3.3 or any later release?
If yes, please ensure that an up-to-date Minimal Reproduction Project (MRP) is included in this report (a MRP is a zipped Godot project with the minimal elements necessary to reliably trigger the bug). You can upload ZIP files in an issue comment with a drag and drop.

Hi. I haven't used Godot 3.x in a while, instead slowly creating an overhauled version of my game project in dev. builds of Godot 4 (to use the SDFGI along with GDScript 2.0). I know it is still pre-alpha, but there has been a marked increase in the ability to tinker and try things out compared to last Spring even.
I can put together an MRP since it shouldn't take much time to create one (that is, when my PC is not doing something else like Cycles rendering).

authors: Ace-Dragon Calinou


text:
Creating a TextureArray with mipmaps results in a black texture

Godot version:
3.1 beta 6
OS/device including version:
Windows 10 GTX 1070
Issue description:
When creating a TextureArray with the MIPMAPS flag enabled, the rendered texture is black
Steps to reproduce:
Download and run the MRP ( actually run the game because I couldn't find a way to create a TextureArray in the editor :( )
Minimal reproduction project:
texturearray-mipmaps.zip

I've just tried generate_mipmaps() which I didn't know about and the texture is still black

It seems that mipmaps are automatically generated for TextureArrays without needing the flag, this is either a bug or needs documenting properly, so I won't close this issue, but I'll leave the code that I found here: https://github.com/godotengine/godot/blob/16e67388a2c46e9d74d866a6cadd4351e8c57a12/drivers/gles3/rasterizer_storage_gles3.cpp#L697

Actually, upon further inspection, only the 1st mipmap is automatically generated and is done so with no regard to if the mipmaps flag is set, this is due to the break happening at the bottom of the loop, so there's definitely something that needs changing here :/

I've had a play around with this, it seems that it's fine if it makes just 1 mipmap (the first one) but if it tries to make any extra mipmaps, you just get a black texture, no errors

Fixed by #26532.

authors: Thource akien-mga


text:
TextEdit font selected color not work

The TextEdit's theme property font_color_selected cant be setup, whether use code or edit the custom colors or edit the theme, the color just keep the font color after it's been selected, others color work fine, and the color selected in the lineEdit works too.

There is an issue template, could you please fill it in ? We need the Godot version, and when you can a video/screenshot of the problem.

I'm still experiencing this bug on 3.2.1 on Windows 10, even though it seems fixed in the sourcecode. Granted, I didn't compile the Engine myself... Is there a possibility that the wrong files were included when compiling the Windows binary or something like that?

authors: firecloud888 groud xarrynator


text:
Splash screen show gray-black colour in ios

Godot version:
Godot 3.1
OS/device including version:
IOS iPhone 6s 11.4
Issue description:

When open app then show gray-black colour in splash screen.
first display white screen image it's added in xcode LaunchImage assets,
after display grey-black colour,
then display godot boot splash  image.
So, how can i remove grey-black colour?
Steps to reproduce:
In godot editor:

set image : project/project settings/ : Application/boot splash/image
export project for ios.

I'll close this issue as no minimal reproduction project was provided in time. This issue can be reopened if someone uploads a minimal reproduction project.

authors: ATOshailesh Calinou


text:
Failing to compile with mono on windows

Godot version:

v3.1.2.devel.mono.custom_build
OS/device including version:

Windows 10
Issue description:

I was able to compile mono recently but suddenly it stopped working and I'm not sure why that is. I did a Visual Studio update recently, maybe that broke something?
When I run the command scons p=windows tools=yes module_mono_enabled=yes mono_glue=no following errors occur:
E:\Godot Engine\Builds\LoL_Call_Maker>scons p=windows tools=yes module_mono_enabled=yes mono_glue=no
scons: Reading SConscript files ...
Configuring for Windows: target=debug, bits=default
 Found MSVC version 14.2, arch amd64, bits=64
Found Mono root directory: C:\Program Files\Mono\
Found Mono JIT compiler version: 6.4.0
Checking for `thread_local` support... supported
YASM is necessary for WebM SIMD optimizations.
WebM SIMD optimizations are disabled. Check if your CPU architecture, CPU bits or platform are supported!
Checking for C header file mntent.h... (cached) no
scons: done reading SConscript files.
scons: Building targets ...
[  1%] Compiling ==> platform\windows\crash_handler_windows.cpp
crash_handler_windows.cpp
platform\windows\crash_handler_windows.cpp(56): error C2039: "string" ist kein Member von "std".
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include\vector(24): note: Siehe Deklaration von "std"
platform\windows\crash_handler_windows.cpp(56): error C3646: "image_name": Unbekannter Überschreibungsspezifizierer
platform\windows\crash_handler_windows.cpp(56): error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von C++ nicht unterstützt.
platform\windows\crash_handler_windows.cpp(57): error C2039: "string" ist kein Member von "std".
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include\vector(24): note: Siehe Deklaration von "std"
platform\windows\crash_handler_windows.cpp(57): error C3646: "module_name": Unbekannter Überschreibungsspezifizierer
platform\windows\crash_handler_windows.cpp(57): error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von C++ nicht unterstützt.
platform\windows\crash_handler_windows.cpp(78): error C2039: "string" ist kein Member von "std".
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include\vector(24): note: Siehe Deklaration von "std"
platform\windows\crash_handler_windows.cpp(78): error C3646: "name": Unbekannter Überschreibungsspezifizierer
platform\windows\crash_handler_windows.cpp(78): error C2059: Syntaxfehler: "("
platform\windows\crash_handler_windows.cpp(78): error C2334: Unerwartete(s) Token vor "{"; sichtbarer Funktionstext wird übersprungen
platform\windows\crash_handler_windows.cpp(79): error C2039: "string" ist kein Member von "std".
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include\vector(24): note: Siehe Deklaration von "std"
platform\windows\crash_handler_windows.cpp(79): error C3646: "undecorated_name": Unbekannter Überschreibungsspezifizierer
platform\windows\crash_handler_windows.cpp(79): error C2059: Syntaxfehler: "("
platform\windows\crash_handler_windows.cpp(79): error C2334: Unerwartete(s) Token vor "{"; sichtbarer Funktionstext wird übersprungen
platform\windows\crash_handler_windows.cpp(105): error C2039: "image_name" ist kein Member von "module_data".
platform\windows\crash_handler_windows.cpp(55): note: Siehe Deklaration von "module_data"
platform\windows\crash_handler_windows.cpp(107): error C2039: "module_name" ist kein Member von "module_data".
platform\windows\crash_handler_windows.cpp(55): note: Siehe Deklaration von "module_data"
platform\windows\crash_handler_windows.cpp(108): error C2039: "image_name" ist kein Member von "module_data".
platform\windows\crash_handler_windows.cpp(55): note: Siehe Deklaration von "module_data"
platform\windows\crash_handler_windows.cpp(109): error C2039: "module_name" ist kein Member von "module_data".
platform\windows\crash_handler_windows.cpp(55): note: Siehe Deklaration von "module_data"
platform\windows\crash_handler_windows.cpp(184): error C2039: "string" ist kein Member von "std".
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include\vector(24): note: Siehe Deklaration von "std"
platform\windows\crash_handler_windows.cpp(184): error C2065: "string": nichtdeklarierter Bezeichner
platform\windows\crash_handler_windows.cpp(184): error C2146: Syntaxfehler: Fehlendes ";" vor Bezeichner "fnName"
platform\windows\crash_handler_windows.cpp(184): error C2065: "fnName": nichtdeklarierter Bezeichner
platform\windows\crash_handler_windows.cpp(184): error C2039: "undecorated_name" ist kein Member von "symbol".
platform\windows\crash_handler_windows.cpp(62): note: Siehe Deklaration von "symbol"
platform\windows\crash_handler_windows.cpp(187): error C2065: "fnName": nichtdeklarierter Bezeichner
platform\windows\crash_handler_windows.cpp(187): warning C4477: "fprintf": Die Formatzeichenfolge "%s" erfordert ein Argument vom Typ "char *", das variadic-Argument "3" weist aber den Typ "DWORD" auf.
platform\windows\crash_handler_windows.cpp(187): warning C4313: "fprintf": "%s" in der Formatzeichenfolge steht mit dem Argument "3" vom Typ "DWORD" in Konflikt.
platform\windows\crash_handler_windows.cpp(187): warning C4473: "fprintf": nicht genügend Argumente für Formatzeichenfolge übergeben
platform\windows\crash_handler_windows.cpp(187): note: Platzhalter und deren Parameter erwarten 4 variadic-Argumente, es wurden aber 3 variadic-Argumente bereitgestellt.
platform\windows\crash_handler_windows.cpp(187): note: Das fehlende variadic-Argument "4" ist für die Zeichenfolge "%d" erforderlich.
platform\windows\crash_handler_windows.cpp(189): error C2065: "fnName": nichtdeklarierter Bezeichner
platform\windows\crash_handler_windows.cpp(189): warning C4473: "fprintf": nicht genügend Argumente für Formatzeichenfolge übergeben
platform\windows\crash_handler_windows.cpp(189): note: Platzhalter und deren Parameter erwarten 2 variadic-Argumente, es wurden aber 1 variadic-Argumente bereitgestellt.
platform\windows\crash_handler_windows.cpp(189): note: Das fehlende variadic-Argument "2" ist für die Zeichenfolge "%s" erforderlich.
scons: *** [platform\windows\crash_handler_windows.windows.tools.64.obj] Error 2
scons: building terminated because of errors.

The first error for example translates to something like
"string" is not a member of "std"
python --version prints 3.7.5
mono --version prints
Mono JIT compiler version 6.4.0 (Visual Studio built mono)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       normal
        Notification:  Thread + polling
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug
        Interpreter:   yes
        LLVM:          supported, not enabled.
        Suspend:       preemptive
        GC:            sgen (concurrent by default)

scons --version prints
SCons by Steven Knight et al.:
        script: v3.1.2.bee7caf9defd6e108fc2998a2520ddb36a967691, 2019-12-17 02:07:09, by bdeegan on octodog
        engine: v3.1.2.bee7caf9defd6e108fc2998a2520ddb36a967691, 2019-12-17 02:07:09, by bdeegan on octodog
        engine path: ['C:\\Users\\USERNAME\\AppData\\Local\\Programs\\Python\\Python37\\scons\\SCons']
Copyright (c) 2001 - 2019 The SCons Foundation

Things I have installed in Visual Studio 2019:

Desktop C++ workload
Desktop .NET workload
MSVC v142 – VS 2019 C++-x64/x86-Buildtools
.NET Framework 4.7-Developertools

Maybe there's something wrong with the compiler of Visual Studio 2019 in the newest version?
Steps to reproduce:
Try generating the glue when compiling with mono using above mentioned versions

Duplicate of #37986.

It should be fixed if you pull the latest 3.1 branch commit.

Yes, you're right, that's the only thing I havent tried... Sorry for the duplicate, I haven't found issues where the errors were similar to mine.

No worry, the duplicate was not easy to find indeed. And I hadn't included the fix in the 3.1 branch yet when your opened this issue, so it was useful of you to open it :)

authors: Grandro akien-mga


text:
Creating a CollisionPolygon2D from a Sprite has an incorrect offset is done from a Sprite with Region enabled

Godot version:

Godot 3.2.4 beta 2
OS/device including version:

Windows 10 , Core i5 , 6gb Ram , Intel Hd graphics card with Nvidia Geforce 920m/pcie/SSE2
Issue description:

When I used the Sprite option  Create CollisionPolygon2D sibling  the result is shown on the left the expected result is shown on the right. This happened when I used a sprite with Region set to true and Auto slicing option selected. The collision shape became offset from the position of the sprite
The original sprite was :

And my sprite was also rotated -90°
Steps to reproduce:
Put the second image provided above into a sprite, set the sprite Region option to true and use  Auto slicing for the texture region and chose any  auto sliced sprite . Then click on the sprite options and create a Collision Polygon Sibling for the sprite you should get a Collision Polygon offset from the position of the sprite by the same amount the auto sliced sprite is offset from the bounding box of the entire sprite as shown below

Minimal reproduction project:

Sprite offset Problem.zip

@lonegod Please upload a minimal reproduction project to make this easier to troubleshoot.

@Calinou  I have uploaded a minimal project

authors: Calinou IoneGod


text:
MOUSE_MODE_CAPTURED not working as expected if mouse is outside of game window when game starts

Godot version:
3.2.3.stable.official
OS/device including version:
macOS Big Sur
Issue description:
I set the mouse mode:
func _ready():
	Input.set_mouse_mode(Input.MOUSE_MODE_CAPTURED)

and observe mouse movement and clicks only when the mouse is captured:
if Input.get_mouse_mode() == Input.MOUSE_MODE_CAPTURED:
...

If the mouse cursor is inside the rectangle of the screen where the game window is going to be displayed, all is working fine. If, however, the mouse cursor is outside of the rectangle, the mouse will be completely captured: the cursor disappears as expected, but clicks still get picked up by the window under the cursor (the game editor, typically).
Expected: since the mode is captured, mouse button clicks should be handled by the game window (just like movement events do)
Steps to reproduce:

Minimal reproduction project:

Interesting, this does not seem to match the behavior described by @name-here, uh, here (even though both are incorrect).

When captured mode is activated, the cursor is warped to the center of the screen, but the mouse position (as printed in your example project) does not update until I attempt to move the mouse. This seems like a minor bug.

Current master seems to have all of the oddities I mentioned above

Can you test this on the master branch? This might be fixed on master. Anyway, adding "needs testing".

#42321 duplicate, should be fixed in master and 3.2.4 betas.

Interesting, this does not seem to match the behavior described by @name-here, uh, here (even though both are incorrect).

I'm on macOS Catalina, so it might be a difference between OS versions?  But I also only tested on that PR and the master branch, not on 3.2.3 stable.

authors: Krumelur aaronfranke bruvzg name-here


text:
HTML5 export does not pack custom C# assemblies

Godot version:
3.2.4.beta4.mono.official
OS/device including version:
Windows 7 Service Pack 1
Issue description:
Trying to export to HTML5 with custom dll libraries (using nuget or by simply referencing the path into the .csproj file) produces an error when loading the web app:
System.IO.FileNotFoundException: Could not load file or assembly 'System.Text.Json, Version=5.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies.
Steps to reproduce:
Export for web by using external dlls like newtonsoft.json or system.text.json, call some methods from the added library inside a script and watch the errors pop up in the browser.

I've been trying the mono game I'm currently working on with different versions with interesting outcomes each time:

3.2.3-stable

Am able to use Newtonsoft.Json successfully - there are issues, however, with any code called on System.Threading.Tasks libraries. When I do Task.Run or task.ContinueWith, I get a Module.cwrap error in the DevTools console and can go no further (though that should I think be fixed with this). Changing all of those occurrences to follow an async/await pattern, the game actually works, though the UI tends to lock up while awaiting.

3.2.4-rc4

Unable to load in the browser due to an issue with the wasm file not having the right MIME type when served through the browser (or even via an export + python3 -m http.server). Sounds like even if I got past this, I'd run into JakSparro98's issue...

3.3-rc5 - rc6

I tried these versions and ran into... something... but can't remember what it was. I'll try them again if anyone needs more info.

3.3-rc8

The game gets to the Loading screen, but when it makes some network calls, I run into some issues (the second one is one that relates to this Issue, and I'll probably make a separate one for the first):

Signals aren't finding methods on parent classes - I have a NetworkService that has a MakeRequest method and in its _Ready will Connect the "request_completed" signal to the virtual "OnRequestCompleted" method on that class. I have an AssetService that is subclassed from NetworkService and calls MakeRequest, but then I see an error in the console that says something to the effect of "Unable to find method on Node AssetService.cs:OnRequestCompleted". If I add that method to AssetService.cs and call base.OnRequestCompleted, it works without raising that error.
After the request is completed and I try to deserialize the JSON with JsonConvert.DeserializeObject<T>(lastResponse), nothing happens - no more log output, and no code is executing any more (the loading screen AnimatedSprite is still running, just no more activity). Here's what the MakeRequest code looks like:

        protected virtual async Task<T> MakeRequest<T>(string url, HTTPClient.Method method = HTTPClient.Method.Get, string body = "") {
            T result = default(T);
            var token = AuthenticationService.Token;
            List<string> headers = new List<string>();
            if(token != null) { headers.Add($"Authorization: {AuthenticationService.Token}"); }
            if(body != "") { headers.Add($"Content-Length: {body.Length}"); }
            var error = request.Request(
                url: url,
                customHeaders: headers.ToArray(),
                method: method,
                requestData: body
            );
            if (error == Error.Ok) {
                GD.Print($"Awaiting request");
                await ToSignal(request, "request_completed");
                GD.Print("Deserializing...");
                result = JsonConvert.DeserializeObject<T>(lastResponse);
                GD.Print("Deserialized");
            }
            return result;
        }

Notice that we should see "Deserialized" in the logs after the object has been deserialized. However, when the game runs in the browser, this is all I see in the last few lines in the output:
Awaiting request
tmp_js_export.js:339 Request completed: 0, 200, System.String[], System.Byte[]
tmp_js_export.js:339 Deserializing...

It never gets to the "Deserialized" log line, so something went wrong trying to do JsonConvert.DeserializeObject.
Earlier logs show that it does seem to be loading in the assembly, so I'm not sure what's going on since there are no errors being raised.

There have been various issues with exporting C# projects to web in releases from 3.2.4 RC 4 to 3.3 RC 6 (see #47048), which are not related to this issue but would indeed prevent confirming it with those releases. 3.2.4 RC 3 had another unrelated bug which would prevent testing: #46352.
From 3.3 RC 7 onward the export should work in simple projects at least, so we should focus on debugging the issue in the latest build.
We'd really need a minimal reproduction project to test and debug further though. Even creating a simple project using a thirdparty C# dependency is not trivial to me with no C# experience (but with a project I can test, confirm the bug, possibly bisect what caused it, etc.).

* with any code called on System.Threading.Tasks

About this, multi-threading is not available in HTML5 platform (can be enabled for regular builds, but not for mono builds, since mono depends on a very old emscripten version).

authors: Faless JakSparro98 akien-mga animanmaster


text:
False positive invalid operands error in gdscript after assignment operator with mixed types

Godot version:
Master f62f64193a5ba54a5e0e74547d0cb0fb54b11258
OS/device including version:
Windows 10
Issue description:
Assignment operator *= with mixed types causes the wrong type to be assessed by the gdscript parser, which leads to a parse error on the next assignment operator.
Example script:
var world_delta = Vector3.ONE
world_delta *= 0.2  # should be still considered Vector3

global_transform.origin += world_delta # triggers parse error

Parse error:
SCRIPT ERROR: Parse Error: Invalid operands "Vector3" and "float" for assignment operator.

It works fine with static typing:
var world_delta : Vector3 = Vector3.ONE
world_delta *= 0.2

global_transform.origin += world_delta

Steps to reproduce:

Add the code above to any Node3D script
OR
Open the MRP and go to script editor

Minimal reproduction project:
bug-assignment.zip

Confirmed still broken on latest master 85186bc

authors: lyuma pouleyKetchoupp


text:
Color Picker in Editor: can't remove preset using RMB

Godot version:
Version 3.3 RC6
OS/device including version:
Ubuntu 18.04
Issue description:
Using the color picker in the editor, I want to delete a color from the second row, but it will delete the ones from the first row.
Steps to reproduce:

In the Scene, click on any node featuring the modulate property.
In the Inspector, click on "modulate" to open the Color Picker
Add lots of colors to the preset, such that a second line of colors appears
try to remove a color from the second line using RMB

Expected: the right-clicked color is removed
Observed: the color from the first line (same row) is removed
In this example, I click the dark purple color, but the red one is removed.

Duplicate of https://github.com/godotengine/godot/issues/43270.

authors: Calinou mrimvo


text:
Losing Internet mid Export Template download crashes Godot

Godot version
3.4.1.stable
System information
Windows 10
Issue description
If you "turn off" the Internet whilst the "Export Template Manager" is downloading it crashes Godot
Steps to reproduce
Open Export Template Manager
Click "Download and Install"
"Lose" Internet.
"Losing" Internet is simply unplugging ethernet/turning off wifi router.
Turning Windows 10 Aeroplane/Flight mode is recognised by Godot as something to manage.
Minimal reproduction project
No response

Turning Windows 10 Aeroplane/Flight mode is recognised by Godot as something to manage.

Does this mean Godot doesn't crash if you enable airplane mode while downloading export templates?

Does this mean Godot doesn't crash if you enable airplane mode while downloading export templates?

Correct, I tested this and Godot appears to timeout in the background then display a message that it will download in the background.
However I just tested this again, i.e. put Windows 10 in "Flight Mode", in the hope of getting a screenshot and it was unable to continue the download, I went to cancel as the message was not appearing and Godot went through a "Not Responding" phase, recovered and showed the message (after it had frozen):

authors: Calinou SoloRobo


text:
NavigationMesh is not being generated at all for HTML5 games

Godot version
3.5.beta1.mono
System information
Windows 10, GLES2
Issue description
When generating a NavigationMesh by using the bake_navigation_mesh function at runtime, the navigation mesh won't be generated at all for HTML5 games. Desktop works fine tho.
When running the minimal project as desktop application it immediately prints "baking done" and you can see the navmesh when debug navigation is toggled. In browser it will never print "baking done".
Prebaked navigation meshes are visible as intended.
Steps to reproduce
Just run the minimal reproduction project, it should show the issue clearly
Minimal reproduction project
MinimalProjectHTML5Navigation.zip

@Spowmtom this issue is for 3.x.
@SlothDevLlama currently runtime baking happens on a separate thread so you need to export your HTML5 project with threading support: https://docs.godotengine.org/en/latest/tutorials/export/exporting_for_web.html#threads
Btw. @SlothDevLlama please don't close this issue - we either need to document baking better or introduce some runtime switch taking threading support into account

@Scony is there for the version I'm using (3.5.beta1.mono) an issue when installing the export template? Since it seems to not beiung able to install the template :-/

authors: Scony SlothDevLlama


text:
The caret in MeshLibrary's name field jumps back to the beginning of the field

Godot version
v4.0.alpha.custom_build [cc5135959]
System information
Arch Linux
Issue description
https://user-images.githubusercontent.com/36025825/181302677-de246a16-a7fa-4fc1-9969-9c3679580d93.mp4
Steps to reproduce

In the FileSystem dock, create a new resource and select MeshLibrary
Double click it and switch to the 3D view
On the toolbar, select the "MeshLibrary" -> "Add Item"
In the Inspector expand the "Item" -> "0" and write something in the name field

Minimal reproduction project
No response

I think this is an issue with all indexed properties (property arrays) in the inspector.

Pretty sure there was a similar issue already reported.
What happens is that when you type something, the inspector gets refreshed, because it receives property list changed notification.

Hi @MmAaXx500, can you please add an MRP or text how to reproduce the error?
I tried reproducing it based on your video, but could not find a way to get the view you have recorded (I am not that familiar with the editor and the codebase yet). If anyone else knows how to reproduce this I'll be happy to look into it :)

@AntonioDell I have added the steps to the OP. I don't think an MRP helps here in any way, because it's not project/setup specific, but if you think otherwise I can add one.

Hi @MmAaXx500, thank you for taking the time to update the post! Sadly following your instructions I can't seem to find the Item array. Can you reproduce the error from the current alpha branch?
Attached you find a screencast where I tried reproducing the view based on the description and failed. Maybe an MRP will help here after all? I wasn't able to build the alpha version you mentioned in the OP, the build on that  commit fails with an error. So maybe this is a new bug introduced in the current master  branch?
Screencast from 07-29-2022 03:18:34 PM.webm

@AntonioDell I recorded the whole process. I'm using cd24fb8 on the video
MeshLib-name-repro.mp4

That was the missing link, thank you! I will look into it :)

Fixed by #63667.

authors: AntonioDell Calinou KoBeWi MmAaXx500 akien-mga


text:
Trim Trailing Whitespace removes indentation on blank lines

Godot version
v4.1.dev.custom_build [b31d00a91]
System information
Windows 10, Vulkan, i9900KF, RTX 2070S
Issue description
When the editor setting "Trim Trailing White Space on Save" is removed in all places. This results in intentionally left blank lines within a function body to be stripped of their indentation.
Expected behavior is to only remove trailing white space on the end of a line containing text. And to conform to user desired indentation.
func get_neighbors() -> Array[Cell]:
	var a: Array[Cell] = []
	-
	for pos in NEIGHBOR_POSITIONS:
		if GridGame.grid.has_cell(pos):
			a.append(GridGame.grid.get_cell(pos))
	-
	return a
-

Correct example above, where - indicates the indentation depth of the line.
func get_neighbors() -> Array[Cell]:
	var a: Array[Cell] = []
-
	for pos in NEIGHBOR_POSITIONS:
		if GridGame.grid.has_cell(pos):
			a.append(GridGame.grid.get_cell(pos))
-
	return a
-

Incorrect example above.
Steps to reproduce
Enable "Trim Trailing White Space on Save", edit a script, ctrl + s.
Minimal reproduction project

See https://github.com/godotengine/godot-proposals/issues/6300

Seems redundant due to proposal.

authors: AThousandShips TheDuriel


text:
Program crashed with signal 4

Godot version
Godot_v4.0-stable_mono
System information
Linux (EndeavourOS)
Issue description
So, working with Godot, the editor is crashing, and I'm getting the following stacktrace. I cannot provide much information since I don't know what may be causing it. I did attach the project so you could reproduce it.
[axel@Endeavour-OS logs]$ godot4_mono --editor /home/drives/HDD_STORAGE/WORK/AXVEMI/GodotProjects/Worlds-Godot/
Godot Engine v4.0.stable.mono.official.92bee43ad - https://godotengine.org
libspeechd.so.2: cannot open shared object file: No such file or directory
OpenGL API 3.3.0 NVIDIA 525.89.02 - Compatibility - Using Device: NVIDIA Corporation - NVIDIA GeForce RTX 2060

Editing project: /home/drives/HDD_STORAGE/WORK/AXVEMI/GodotProjects/Worlds-Godot
Godot Engine v4.0.stable.mono.official.92bee43ad - https://godotengine.org
libspeechd.so.2: cannot open shared object file: No such file or directory
Vulkan API 1.3.224 - Forward+ - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce RTX 2060

[axel@Endeavour-OS logs]$ WARNING: Blend file import is enabled in the project settings, but no Blender path is configured in the editor settings. Blend files will not be imported.
     at: _editor_init (modules/gltf/register_types.cpp:70)
ERROR: FATAL: Condition "!match" is true.
   at: ~CSharpInstance (modules/mono/csharp_script.cpp:2022)

================================================================
handle_crash: Program crashed with signal 4
Engine version: Godot Engine v4.0.stable.mono.official (92bee43adba8d2401ef40e2480e53087bcb1eaf1)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /usr/share/dotnet/shared/Microsoft.NETCore.App/7.0.3/libcoreclr.so(+0x4a899e) [0x7fc8a46a899e] (??:0)
[2] /usr/lib/libc.so.6(+0x38f50) [0x7fc8cbcecf50] (??:0)
[3] /usr/local/bin/Godot_v4.0_mono/Godot_v4.0-stable_mono_linux.x86_64() [0x1589f68] (??:0)
[4] /usr/local/bin/Godot_v4.0_mono/Godot_v4.0-stable_mono_linux.x86_64() [0x464be71] (??:0)
[5] /usr/local/bin/Godot_v4.0_mono/Godot_v4.0-stable_mono_linux.x86_64() [0xee3b50] (??:0)
[6] [0x7fc8285e010d] (??:0)
-- END OF BACKTRACE --
================================================================

Steps to reproduce
Open the attached project
Open scenes => WorldGenerator.tscn
In the scene tree, inspect Node. It should have the WorldManager script attached.
Play with the settings (Grid Width and Grid Height) and click on Refresh to try it. It usually crashes when changing from 2x2 to 10x10 or like that. Not always.
Minimal reproduction project
Worlds-Godot.zip

Duplicate of https://github.com/godotengine/godot/issues/70449

Duplicate of https://github.com/godotengine/godot/issues/70449.

authors: Calinou RedworkDE axvemi


text:
Inspection does not reload data if variable changed in code.

Godot version
4.0.1 stable
System information
Window 10, 3080,
Issue description
I am making an inventory and I accidentally deleted my item resource.  I had already made a bunch of items, so I remade my item resource.  Well, this I changed one of the variable names from description to desc.  Having remade item I opened one of the items I have made to see if it still worked.   Everything did but the description.  So, I go back into the item.gd file and change desc to description and open another item.  It still was blank, I assume it already loaded a blueprint of item.gd and did not reload it for the saved items.
Closed Godot and reopened it, and its fine.
Steps to reproduce
Make Resource file
Create a tres from resource file.
Save Tres with data.
Rename variable in Resource file.
Tres does not update until Godot is closed and reopened.
Minimal reproduction project
extends Resource
class_name item
@export var name: String =""
@export_multiline var description: String = ""
@export var texture: Texture
Changed Make a resource.
change name to desc. Save.

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

Related to Reloading a scene won't reset exported custom resource properties #57268.

Thank you for your help, I'm not huge into using github, but this is a fantastic project and I wanted to help.

authors: Calinou Soliaonline


text:
Autocomplete don`t work in some specific cases (self and direct class hierarchy)

Tested versions

reproducible in 4.2.1

System information
Godot v4.2.1.stable unknown - Manjaro Linux #1 SMP PREEMPT_DYNAMIC Fri Mar  1 18:16:16 UTC 2024 - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4070 Ti SUPER (nvidia; 550.54.14) - Intel(R) Core(TM) i7-14700KF (28 Threads)
Issue description
It is quite often practice to use self. for recognition class defined
variables  usage from local variables usage which are without self prefix.
In current moment in situation like in screenshot autocomplete fail to work .
Working autocomplete (no self ):

Not Working autocomplete (using self ):

Also persist situations in case of usage Enums autocomplete working only for Global scope enums usage
Like in screenshot :
Working enum autocomplete using global enum scope:

But in case if used direct class member Enum define in parameters which is quite logical and predictable . Autocomplete fail to work.

Steps to reproduce
steps to reproduce so simple and do not require anything special
Minimal reproduction project (MRP)
it is not required any project and reproducible even with one node and default binded script.

The part about self is solved, see:

https://github.com/godotengine/godot/issues/85833

Please try 4.2.2.rc2

The second part I'm unsure about, that's an unusual way to access an enum

As mentioned before, the self problem is already fixed on master. Your enum problem is a duplicate of #88858 and would likely be fixed by #89382. So I'd suggest closing this issue as duplicate.

Hi . Sorry for dupe.
Yes we  can close


text:
Bad normals when importing mesh using .blend from Blender 4.1

Tested versions

Tested in Godot 4.2.2. stable

System information
Godot v4.2.2.stable.mono - Windows 10.0.19043 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2060 (NVIDIA; 31.0.15.4584) - Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz (12 Threads)
Issue description

When importing a mesh using the .blend auto importer, it appears that with auto-smooth enabled the normals are broken. This occurs when using Blender 4.1, but not Blender 4.0. One major difference is the auto-smooth feature had some changes (it marks sharp edges on the mesh immediately rather than later).
If it helps, exporting as .glb from Blender 4.1 seems to result in good normals.
Steps to reproduce

Open a new project
Open a .blend import with auto smooth enabled. I have attached the mesh I made in the MRP.
View the meshes in the editor, or add to a test scene. The Blender 4.0 mesh looks fine, while the 4.1 mesh is cursed.

Minimal reproduction project (MRP)
NormalIssueTest.zip

My bad, incorrect importer version set.


text:
Make generated .h files with some common extension

Issue description:
As evidenced by #9223, various autogenerated .h files are gitignored individually, which leads to some slight issues when switching between branches and the like.
I propose that we make up some more complex extension for them (like .gen.h), so that we can ignore them all at once, or even, put them in some special generated/ folder.

I think using a .gen.h extension is a good idea.

👍

authors: akien-mga bojidar-bg vnen


text:
Add texture atlas support for SpriteFrames

Operating system or device - Godot version:
ALL
Issue description:

AnimationSprite is an easy way to create frame animations, but we can not put all the frame images in a single file.
Steps to reproduce:
Link to minimal example project:

it would be better to support multiple animations in one sprite sheet.
For example, we can put walking, running and jumping frames in one sprite sheet, and set the "start frame" and "end frame" for each animation.
Thanks!

@alexzheng Don't worry, we would probably go as far as to support texture atlases (unaligned frames) and using the frames in any order that one might want (which would imply being able to use only some of the frames of an animation).

amazing

Can't you just import all your frames into a single AtlasTexture and load the single .atex files into your SpriteFrames? This is what I'm doing and it works just fine.
Or do you mean something else?

@timoschwarzer you can, but it isn't intuitive enough.

What is your suggested way of doing it?
For me this way works just fine and is intuitive enough due to its flexibility.

First of all thank you for your report and sorry for the delay.
We released Godot 3.0 in January 2018 after 18 months of work, fixing many old issues either directly, or by obsoleting/replacing the features they were referring to.
We still have hundreds of issues whose relevance/reproducibility needs to be checked against the current stable version, and that's where you can help us.
Could you check if the issue that you described initially is still relevant/reproducible in Godot 3.0 or any newer version, and comment about its current status here?
For bug reports, please also make sure that the issue contains detailed steps to reproduce the bug and, if possible, a zipped project that can be used to reproduce it right away. This greatly speeds up debugging and bugfixing tasks for our contributors.
Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.
Thanks in advance.
Note: This message is being copy-pasted to many "stale" issues (90+ days without activity). It might happen that it is not meaningful for this specific issue or appears oblivious of the issue's context, if so please comment to notify the Bugsquad about it.

The SpiteFrames editor would be even more convenient if you could open image, specify the number of rows and columns, and the frames would be automatically imported.

Maybe not the exactly the solution you guys wanted but I made a script for Spritesheet Packer that allows publishing a spritesheet directly as an AnimatedSprite.

Fixed in 3f76d2c2

authors: KoBeWi alexzheng bojidar-bg dalexeev kubecz3k piratesephiroth timoschwarzer


text:
Font subpixel antialiasing results in artifacts

Tested versions

Reproducible in 4.4.dev [694d3c2930bdfb43fd93e1e6641f66c4f19a5c77]
Reproducible in 4.4.dev [2c136e6170a40f58f2dfb89d32eadfca7156ef37]
Not reproducible in 4.4.dev [14a7e0abb313915fc5e4f36b34f9169b1d45774c]

System information
Godot v4.4.dev (2c136e617) - Windows 11 (10.0.22631) - Vulkan (Mobile) - dedicated NVIDIA GeForce RTX 4070 Laptop GPU (NVIDIA; 32.0.15.6109) - AMD Ryzen 9 7940HS w/ Radeon 780M Graphics (16 Threads)
Issue description
As best I can tell (using git bisect) this looks to be a regression caused by #92797.
When using the "LCD Subpixel" value of the editor setting interface/editor/font_antialiasing, on Windows 11 in my case, I end up getting rendering artifacts around a lot of the text in the editor, which looks like this:

This is what it looks like when using the default grayscale antialiasing:

Here's what subpixel antialiasing looks like up close:

Here's what the grayscale equivalent looks like up close:

Steps to reproduce

Open the editor.
Set the interface/editor/font_antialiasing editor setting to "LCD Subpixel".
Wait for the editor to update everything.
Note the artifacts.

Minimal reproduction project (MRP)
N/A

Can confirm I'm seeing oddities, so I'll take a look. Thanks for the report!

Found the issue, and is fixed in #97217

authors: mihe stuartcarnie


text:
Warnings when compiling on Linux with LTO

Tested versions
Built from master [506d6e427a4eecfc1e5e5ee1180019a876119701]
System information
Operating System: Debian GNU/Linux 12 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.0-25-amd64 (64-bit) Graphics Platform: X11 Processors: 6 × Intel® Core™ i5-9600K CPU @ 3.70GHz Memory: 9.4 GiB of RAM Graphics Processor: SVGA3D; build: RELEASE; LLVM; Manufacturer: VMware, Inc. Product Name: VMware Virtual Platform System Version: None
Issue description
Compiling Godot on Linux produces warnings:
Linking Program bin/godot.linuxbsd.template_release.x86_64 ...
thirdparty/freetype/src/autofit/afglobal.c: In function 'af_face_globals_new':
thirdparty/freetype/src/autofit/afglobal.c:344:5: warning: 'memset' writing 696 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
  344 |     FT_ZERO( &globals->metrics );
      |     ^
thirdparty/clipper2/src/clipper.engine.cpp: In function 'AddPaths_':
thirdparty/clipper2/src/clipper.engine.cpp:625:53: warning: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=]
  625 |     Vertex* vertices = new Vertex[total_vertex_count], * v = vertices;
      |                                                     ^
/usr/include/c++/12/new:128: note: in a call to allocation function 'operator new []' declared here
  128 | _GLIBCXX_NODISCARD void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc)
      |
scene/resources/animation.cpp: In member function 'commit_temp_packets':
scene/resources/animation.cpp:4522:48: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
 4522 |                         header[header_bytes++] = 0;
      |                                                ^
scene/resources/animation.cpp:4500:25: note: at offset [9, 14] into destination object 'header' of size 8
 4500 |                 uint8_t header[8];
      |                         ^
scene/resources/animation.cpp:4522:48: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
 4522 |                         header[header_bytes++] = 0;
      |                                                ^
scene/resources/animation.cpp:4500:25: note: at offset 15 into destination object 'header' of size 8
 4500 |                 uint8_t header[8];
      |                         ^
scons: done building targets.
[Time elapsed: 00:07:56.49]

Steps to reproduce

git clone https://github.com/godotengine/godot --depth 1
cd godot
Download custom.py.txt file below
Rename it to custom.py and move into the godot directory
scons p=linux target=template_release

Minimal reproduction project (MRP)
custom.py.txt

Duplicate of #88504, consolidating there. I'll add the animation warnings which seem newly introduced.

Actually I can't reproduce the animation warning with GCC 14.
It's a false positive from GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104789
We already worked it around in #58755, which seems to still work ok for me, but maybe not for GCC 12 which might have had more issues with this case.

I'm not sure if there's an easy way to upgrade GCC on Debian, there would be on Ubuntu but I wouldn't advise mixing packages. Debian prides itself in stability and this usually means relatively old libraries and toolchains, which aren't always great for software development.
But you can ignore these warnings, they're not impacting anything. And getting a newer GCC would only remove the animation one but not the ones generated in thirdparty code, which can't be disabled due to another GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922

authors: Swarkin akien-mga


text:
AnimationPlayer: checkbox of property AudioStreamPlayer:playing is invisible if the value is animated true

Tested versions

Reproducible in: 4.3.stable, v4.4.dev3

System information
Debian Linux/X11 12.7, xfwm4 4.18.0 with built-in compositor, AMD RX 550, Compatibility renderer
Issue description
when animating the property AudioStreamPlayer:playing, the checkboxes are only visible when the value is set to false. if the value is true, the checkbox is invisible — and it cannot be clicked: it must be drag‑selected

Animation panel showing an animation with the tracks AudioStreamPlayer:playing and ColorRect:visible being animated identically.
the checkboxes on the ColorRect:visible track look and act normally,
only the checkboxes on the AudioStreamPlayer:playing track are bugged

Steps to reproduce

create a new Godot project
create a scene with an AnimationPlayer and an AudioStreamPlayer
add a sample to the AudioStreamPlayer
animate the proprety AudioStreamPlayer:playing using the AnimationPlayer

Minimal reproduction project (MRP)
2024-10-24_music-animation-bug.zip (5.4 KiB before extracting and opening in Godot, 4.1 MiB after)
(credit: sample is located under shapes/micro.wav in LMMS built‑in samples)

This specific property is handled in a special way, playing a track rather than setting the value, see:

https://github.com/godotengine/godot/issues/54183

It is pretty unintuitive though

Also just want to thank you for a very nicely filled in issue report, don't think I've ever seen an image description before but it is such a great help, both for accessibility and for understanding what the image is meant to convey, I'll make a note of this for our issue triage improvements and add it as a suggestion 🧡

This specific property is handled in a special way, playing a track rather than setting the value

ah: the keyframes are meant to show the waveform of the sample but if the sample is too short, it fails to show anything.
starting yesterday, i will use sub‑second samples a lot for musical drafting, so i need good visualizing of short samples; something like this:

a keyframe set to false could be an empty checkbox
a keyframe set to true could be

the waveform if the sample is long enough
a thin bar with a minimum visible width — maybe half as wide as a checkbox — if the sample is too short

authors: AThousandShips sosasees


text:
Perfect FreeType-based outlines for DynamicFonts

Implement outlines based on FreeType Stroker API. This allows
artifact-free results, similar to what you will see in Web or any text
editing tools. Outline parameters are a part of DynamicFont rather
than Label, because outlines have to be baked into the font's atlas
along with the characters.

Add optional no_outline parameter to Font::draw_char so that shadows
can be rendered as expected - without including the outline.

Add start_draw_batch/end_draw_batch methods which are supposed to be
called before/after a series of draw calls. This is needed because all
outlines in a text have to be rendered before the characters. This
also allows potential optimizations for text rendering.

Number of draw-calls is reduced from 5 to 2 per outlined character.

Overall cleanup of DynamicFont code, extracted duplicated code pieces
into separate methods.

The change is backward-compatible - Labels still have outline
properties that work exactly as they worked before.

Closes #16279.

I've added a fix to #15787 as a separate commit to this branch since it requires a change to dynamic_font.cpp which was heavily refactored here.

I feel hashing the font color is way too much overkill and allows itself to be heavily misused.
I would only either:

Just allow black outlines
Find a way to draw the font outline separately (as in, only outline) so they can be composited.

I am pretty sure it should be possible to draw outlines only, right? if we can separate outline from font, we can composite them on demand and for different colors if needed.

Could you please clarify how hasing is an overkill and could be misused, especially when it's local to the font type? I don't get it.

The problem is not hashing itself, but having a font version for every outline color. What I wonder is if the outline can be composited in two draw calls to avoid this (both have a caret for char and for outline and draw them together).

Updated the PR based on discussions with @reduz.

There are now separate DynamicFontAtSize instances created for base font and its outlines, which means there will be no additional memory usage if the same font has multiple different outline sizes. Having different outline colors also does not affect the amount of memory used.

Batching is now done externally to the Font object rather than internally, which means it's a responsibility of clients to call draw_char twice - first to render an outline for the whole text and then to render the characters themselves. FontDrawer was added to help with this in engine code, but scripting clients still have to take care of that. Should not be a problem though since using Font::draw_char from a script directly is a rare use case.

font_outline_modulator property was added to Label class - it's used as a multiplier for the font's own outline color. Is the name OK?

@reduz I've updated it based on what we agreed on - see my previous comment. I've now also resolved the conflicts which occurred after that.

font_outline_modulator property was added to Label class - it's used as a multiplier for the font's own outline color. Is the name OK?

font_outline_modulate would sound more consistent with the modulate and self_modulate properties we currently have in Node.

True, modulate is used as a color property name in few places, even though it's a verb and not a noun. I've updated the property name to font_outline_modulate for consistency.

Thanks!

Could this be cherry picked for 3.0.3? As it fixes the issue with oversampling #15787 and that one is very annoying when you want to have multiple resolutions

May be too late for 3.0.3, but maybe @hpvb knows better. :P I'll add the cherrypick label regardless, maybe there will be a 3.0.4 before 3.1.

Hi, I'm using
Godot Version: 3.06.stable.official.8314054
Windows Version: Windows 10 64-bit on Surface 4 Pro (with HDPI monitor)
Today, I've experimented the issue #15787 (DynamicFont occasionally broken with oversampling enabled).
Not sure if this is the correct place to report this, but I noticed that it happens when:

Set a custom font and save as .tres file
Set another custom font with the exact same settings (font file and size) and save it in another .tres file
create a scene with two labels
assign the first .tres custom font preset to the first label
assign the second .tres custom font present to the second label (basically, you have two labels in the same scene that read the custom font preset from two different files that has the same settings)
with "use oversampling" option activated, when I try to scale the window the #15787 error appears, and the debugger/errors tab in the editor, list hundreds of this error:

0:00:04:0453 - Condition ' !id_map.has(p_rid.get_data()) ' is true. returned: __null
Type:Error
Description:
Time: 0:00:04:0453
C Error: Condition ' !id_map.has(p_rid.get_data()) ' is true. returned: __null
C Source: core/rid.h:165
C Function: getornull
The error disappears:

Disabling the "use oversampling" option, but also
Just setting different font size in one of the .tres custom font present (if the two presets have the same font but different size everything seems works fine)

Hope this can help (and sorry for my bad English)

Now that Godot 3.1 has been released, we don't plan to cherry-pick new features and enhancements to the 3.0 branch, unless there is very strong support in favor of it. Removing cherrypick label for 3.0.

source: gharchive/pull-request

authors: AlessioCorridori Calinou Nobelix akien-mga endragor mhilbrunner reduz


text:
Fix to scrolling, rounding error on max_v_scroll

Fix to #22744

Using the test project provided by @KoBeWi, in both the master and a build with this cherry-picked, it appears to be working just fine.

Thanks, looks good.

authors: akien-mga avencherus kellams


text:
Initial color management support

This adds LUT based color management on the Rasterizer layer, to ensure that all content blitted
to screen are processed exactly once. Rasterizer::set_screen_lut and VisualServer::set_screen_lut are added. Implemented for both GLES3 and GLES2.
The feature is accessible under Editor Settings / Interface / Color Management. It depends on LittleCMS to handle ICC profiles. This implements #26826.

EDIT: Updated OP to reflect current state of the branch. Again.

The feature is put behind a new command line flag --cm-lut, as I don't believe the interface is suitable for end users yet. Note that the flag is lost when you open an editor from the project manager.

Would this be better suited as an editor setting? This way, it would be preserved when editing a project using the Project Manager.

Would this be better suited as an editor setting? This way, it would be preserved when editing a project using the Project Manager.

Possibly, although I don't think it's very easy to use right now You still have to generate the LUT outside Godot somehow. I think an option for an ICC profile would be more fitting for an editor setting, in that it's an "easy" interface. That requires dependency (or a new ICC profile parser) however.
I can make it an editor setting if that's ok. Could you enlighten me a bit on the proper place in the code base to add a new setting?

Related to #26101 by @QbieShay.

#26101 and this PR address different needs. The former is for "in-game" grading (artistic effect), while this one is for global output gamut conversion (sRGB -> device gamut), intended to be used with the editor.

I am not sure this needs to be in the core. I think it might better suit a plugin.

I am not sure this needs to be in the core. I think it might better suit a plugin.

This needs to happen in Rasterizer to ensure that all outputs to screen are processed exactly once. I'm not aware of a way to plug into the Rasterizer. This cannot be a Node because:

A Node can be added multiple times. As a result, some content can be transformed more than once.
A Node is not guaranteed to be processed as the last step of rendering. As a result, some content may get rendered without being transformed.

Because this feature is for color space conversion, not artistic effect, both situations are entirely undesirable. That leaves me no options other than putting it in the core. For more detailed background of this PR please see #26826.

Minor correctness fix in the shader and rebased on current master.
Moved clamp before texel alignment, so in the off case that HDR data is passed to this shader it would not wrap and print bad colors.

I have pushed an alternate version which allows users to choose an ICC profile in editor settings. It depends on LittleCMS for profile handling.
@Calinou Do you think this is better?

It does not need to be in the rasterizer. You can use a screen shader to do so.

It does not need to be in the rasterizer. You can use a screen shader to do so.

So where do I apply this screen shader?

I would say by using a Color rect node, taking the full scree size, and using SCREEN_TEXTURE as input. But indeed that requires that you have only one of them, and  that it is put on top of your display.
But I mean, it might be OK as built-in, as long as it is a needed feature. Which I am not sure it is in the general case.

SCREEN_TEXTURE does not take into account stuff using transparent pipeline, though (so anything with alpha won't show)

@groud in that case I vote for world environment

@groud in that case I vote for world environment

Yeah it might make sense there.

@groud I'm not exactly sure how I can make sure that the ColorRect stays where it should without touching core stuff. AFAIK anyone can just place Nodes where they like.
I certainly believe this is needed as I need it, but I do understand that the rest of the community may not care about working with other color managed applications. If the community decides that this is unnecessary I'll respect the verdict.
@QbieShay This feature and your contribution work together. Where artist can use your tools to convey their vision, color management ensures that the exact vision is shown on the screen as correctly as possible.

AFAIK anyone can just place Nodes where they like.

Yeah, but that's not a problem. It is not up to us to check if users are using a node correctly (we must document things though) It's like, you cannot complain about one of your camera not working if you put cameras in your tree.
Anyway, I think that if it should be built in it has to be a parameter of a WorldEnvironment node, as @QbieShay suggested.

AFAIK anyone can just place Nodes where they like.

Yeah, but that's not a problem. It is not up to us to check if users are using a node correctly (we must document things though) It's like, you cannot complain about one of your camera not working if you put cameras in your tree.
Anyway, I think that if it should be built in it has to be a parameter of a WorldEnvironment node, as @QbieShay suggested.

It appears that you have misunderstood the purpose of color management. This is not related to WorldEnvironment and is not something artists tweak or even put into the end game. It's for the editor itself, so that colors are correctly translated from sRGB to the color space of your monitor, so that they do not appear over-saturated and blown out.
WorldEnvironment does not work with 2D and most importantly does not reach the Editor UI, so it doesn't cover the use case at all.

Ah indeed sorry. If it's required for specific hardwares and in the editor it indeed has to be built in. Sorry for the inconvenience.

No inconvenience felt. It's sad but true that color management is little known or understood outside the artist/photographer crowd, but it's a great thing and we should work to make it more mainstream!

Added support for GLES2.
I accidentally created a doppelganger commit while rebasing which triggered a review from neikeq because apparently I can't count commits...

Rebased on current master branch.

Ah indeed sorry. If it's required for specific hardwares and in the editor it indeed has to be built in. Sorry for the inconvenience.

Unnecessary perhaps, but to add furthermore to this, godot has been claiming linear workflow to be supported this whole time where it seems to me that has not been the case. If color management was not properly supported up to now, then any linear workflows/content pipelines were effectively broken this whole time, too. That is admittedly assuming artists working both in their dedicated DCC's as well as evaluating their assets in editor.

@Megalomaniak This PR adds display profile awareness (sRGB to device space, i.e. "Color Management" as in Krita/Photoshop/GIMP/...) to Godot. For conversion from scene linear to sRGB (i.e. "Color Management" as in Blender), you'll want to look at Godot's scene rasterizer and the tonemapper options in the Evironment resource.
What you're referring to is not in the scope of this PR, and would have the best chance of getting considered/implemented by the community if you create a new issue for it.

Yes, I understood that, but as I said, this is important too for those that are evaluating their work in godot. That is exporting from dcc and then importing to godot to view it there.

Is it possible to get Window's device LUT automatically?

Little CMS has a thread on the topic of getting Window's default device profile. https://sourceforge.net/p/lcms/mailman/message/19649917/

This pr should get the ability to get Godot's current monitor and that monitor's device profile and set it as the screen lut.
Platforms:

Windows 10
Mac
Linux

May be specific to the desktop manager? Will need investigation.

Can you update https://github.com/godotengine/godot/blob/master/thirdparty/README.md for the license information of LCMS?

Can you update https://github.com/godotengine/godot/blob/master/thirdparty/README.md for the license information of LCMS?

@fire This PR does contain an update to that file. See https://github.com/godotengine/godot/pull/26869/files#diff-6a71cf880a735be694f22266c46ec066

This pr should get the ability to get Godot's current monitor and that monitor's device profile and set it as the screen lut.

I agree that the feature is nice to have, but I don't believe it's immediately necessary for this PR to work. I think it's more appropriate as a separate PR, after/if the base functionality get merged.

Sounds good.

Rebased and resolved merge conflicts.

Some errors compiling on windows:
1>cl : Command line warning D9025: overriding '/w' with '/W3'
1>cl : Command line warning D9002: ignoring unknown option '-std=c99'
1>cl : Command line warning D9002: ignoring unknown option '-O3'
1>cmscgats.c
1>thirdparty\lcms2\cmscgats.c : warning C4828: The file contains a character starting at offset 0x2748 that is illegal in the current source character set (codepage 65001).

Will report what happens when I start Godot.

I tried the PR it works. If I apply the icm profile twice by removing it and apply it. The twice application causes the editor to turn darker than normal. Not sure if it's related.

Here is some research for how to fetch the device's icc profile and links:

https://stackoverflow.com/questions/13533754/code-example-for-wcsgetdefaultcolorprofile
Posted a question for OSX (https://stackoverflow.com/questions/56898204/get-osx-icc-default-color-profile-from-c)

If I apply the icm profile twice by removing it and applying it causes the editor to turn darker than normal. Not sure if it's related.

@fire There is an unrelated bug in Godot where the background dim from modal dialogs (e.g. engine settings & file browser) will persist after closing in some cases. That one looks like what you're getting. It may have something to do with the lag that LUT generation introduces, but I don't think fixing that within this PR's scope.

errors compiling on windows

I'll check the build scripts on Windows as soon as possible.

how to fetch the device's icc profile

Thanks for the pointers. I'll get to it after/if the base functionality get merged.

@toasteater Can you point me to the bug number for the background dim?

@fire Didn't find an existing report, so I reported it at #30368, along with a way to reproduce it.

Since this impacts the renderer and conflicts with the work done in the vulkan branch, this will have to wait for after the 3.2 release to be merged. At that point it will also need to be rebased once the vulkan branch is merged in master.
It can still be reviewed and tested as is, but merging it now would make rebasing the vulkan branch trickier (and this wouldn't be implemented for Vulkan either).

@toasteater Since the vulkan branch has a 2d branch in theory we could try this in the editor.

@fire I don't see a separate 2d branch. Maybe I don't have the permissions? In any case I'd rather wait until things get more stable, after it's merged in master at least. 4.0 still seems very far away, I don't think rebases make sense currently.
That's said, if anyone wants to pick this feature up and start maintaining it for vulkan right now, please feel free to do so. From what I've seen about the vulkan branch, you probably have to do the rasterizer stuff from scratch, so the only thing you could reuse is the cm module, which is just rather trivial glue. If anyone is interested, please let me know!

Closing because I no longer have the intention to port the feature to 4.0. Again, if anyone is willing to pick this up, please feel free to do so.

I want to have this feature in 4.0

There are two commits in this PR. The first one adds LUT support at Rasterizer level, and the second one adds lcms glue and the user interface. Only the first one should conflict with vulkan.
I think if you implement set_screen_lut and modify blit_render_targets_to_screen for RasterizerRD, you can just cherry-pick the second commit and it should just work. For blit_render_targets_to_screen you need to write a shader to sample the LUT. Texel offset must be taken into consideration, or you'll get wrong colors from interpolation. The LUT itself is a cube texture with X as R, Y as G, Z as B.
The sampling has to happen at blit_render_targets_to_screen (instead of, say, during tonemapping), to ensure that everything is transformed once and only once.

@toasteater Is it ok to change the design so the lut is per rendertarget?

I am salvaging this.

authors: Calinou JFonS Megalomaniak QbieShay Zireael07 akien-mga fire ghost groud toasteater


text:
Fix Multiline texts not updating correcly inside arrays

The deferred call was from #24792, and from what I tested, it didn't bring back the bugs it solved.
Fixes #28021.
Supersedes #31165.

Thanks!

authors: YeldhamDev akien-mga


text:
Implemented 'Auto width' behaviour to the ItemList to complement the existing 'Auto height'

I have implemented the 'Auto width' in ItemList. This is also in response to https://github.com/godotengine/godot/issues/31504
The behaviour in this pull request should be identical to the existing 'Auto height', i.e. : expands the container & parent containers with the content but does not shrink the container or any parent container.
This change is a minimal change that serves to complement the existing 'Auto height' but perhaps both options should be updated to both shrink & expand with the contents?

I will recreate the pull request from a separate up-to-date branch.

A new up-to-date pull request has been created (and present on a separate branch rather than the master fork) : #33774


text:
Allow using Rider MSBuild on Windows, when Rider is selected as external editor

JetBrains MSBuild is preferable over Microsoft one, because MS one has a requirement for a valid Visual Studio license. See more https://blog.jetbrains.com/dotnet/2018/04/13/introducing-jetbrains-redistributable-msbuild/

Thanks!

Cherry-picked for 3.2.1.


text:
Fix script used as type gone too early (3.2)

Following up on what I explained in #42323, it seems that the problem with Variant's Object * constructor was very needed. The only thing that was preventing me from doing it is that GDScript was leveraging the wrong behavior. However, it seems that @vnen already fixed that.
I've cherry-picked the commit that removes that naughtiness from GDScript and the definitive fix for Variant has become possible. Variant will now manage the lifetime of a Reference nicely even if it's assigned via the Object * constructor. As I explained in the mentioned PR, without that fix, two incompatible reference counting mechanisms were being used simultaneously, which was nothing else than summoning the most terrible forces in a cold and stormy night.
NOTE: 4.0 already gets this right.
Fixes #43042.

Release builds fail with:
core/variant.cpp:2347:14: error: no member named 'rc' in 'Variant::ObjData'
                _get_obj().rc = NULL;
                ~~~~~~~~~~ ^
1 error generated.

I'm still researching what is going on (still pretty new to Godot internals) but I think this is causing problems if I try to use duplicate with a GDScript class only meant to hold data.  I am using the Resource::duplicate() to make copies at points and I am getting an unhandled exception in Object::set.
I've applied this PR on top of a fresh copy of 3.2.4 beta 1 BTW.

@ChainedLupine, a minimal reproduction project would be appreciated.

@ChainedLupine, a minimal reproduction project would be appreciated.

Here you go!
PR43049.zip

I've cherry-picked a fixup by @vnen that was needed.
@ChainedLupine, I don't have time now to test your project. Could you test this PR again on it?

Just to verify I reverted to 2e073ecbeaf5b502c2b8c3c0510e4a22a56db58 and I'm not getting the crash.  It's definitely something in this PR which is causing a problem with duplicate().

I can confirm that with the latest 3.2 commit (318ae4d047ccde74c2a1e2b3af7f030c35cb108e) (+ local cherry-picks unrelated to GDScript) I don't get any issue with the project in https://github.com/godotengine/godot/pull/43049#issuecomment-717559858.
Haven't tried with the PR yet but this needs to be addressed before merging.

I've narrowed it down to the changes in variant.cpp.  For some reason, when Object::set_script occurs in the cloned Resource, the script_instance seems to refer to a ScriptInstance with no implementation.  So when script_instance::set occurs, there's an unhandled exception.

I've been investigating this. The same happens in 4.0, where Variant::Variant(Object *) "detects" References, as this PR does.
The problem is that if a Reference which has not gotten it's ref. count initialized is assigned to a Variant, it will initialize it and then decrement it at destruction. The result is that the object is released.
That is happening to the self variable in GDScriptFunction::call(), when called during the duplication of the resource. The moment the script property is copied and such script is called on a still-unreferenced Reference which is the duplicate Resource.
I can think of two ways to fix this:

Modify Resource::duplicate() so that the Ref<Resource>(r) is created from the very beginning.
Modify Variant so it doesn't increment/decrement the ref. count of a Reference if it's not already initialized when it's assigned.

I'd like to hear @vnen's opinion again. I'm not sure if option 2) would have unintended side effects. We could just do 1) and consider an error assigning a not yet referenced Reference to Variant.

@ChainedLupine, by the way, thanks for the test project and your insights!

Aha!  That explains why the self reference is hollowed out after it finishes running the initializer during set_script, because it's pointing to just the abstract class and not a real object.  Now I understand what is going on.
@RandomShaper Thanks for figuring it out, I am so glad I could help!

To recap on the situation:

What this PR does seem to be correct.
If fixes some issues that were introduced by "the dangling Variant fix".
However, since this PR makes Variant more clever (the same way it is in 4.0), it uncovers a bug that is both on 3.2 and 4.0, which I explained in a comment above.
The plan could be getting the issue common to 3.2 and 4.0 fixed and then merge this, or if the benefits this PR provide are considered bigger than the uncovered issue, merge it right away and file a bug for such issue, which anyway needs to be addressed before the next release.

Thanks!

authors: ChainedLupine RandomShaper akien-mga


text:
Add a unit test suite for GDScript

This tests run-time script loading and is a complement to the existing integration tests.

Shouldn't this go in modules/gdscript/tests/ together with other GDScript tests? And then might need a more explicit name as test_gdscript.h already exists.

Shouldn't this go in modules/gdscript/tests/ together with other GDScript tests? And then might need a more explicit name as test_gdscript.h already exists.

Yes, but I'm not sure if this will work, but should likely work... Yet maybe Calinou has other motivations for doing so. But yeah, I'd prefer to have all GDScript related tests to be under modules/.

Shouldn't this go in modules/gdscript/tests/ together with other GDScript tests? And then might need a more explicit name as test_gdscript.h already exists.

Done. I ended up just moving the test case into the existing GDScript test suite.

Thanks!

Hm, this is actually crashing for me because the language has not been initialized.

authors: Calinou Xrayez akien-mga vnen


text:
WIP: Make MenuButton's switch_on_hover work again

Since Popups were made into full-fledged windows, the switch_on_hover feature (which allowed to switch from the popup of one MenuButton to another) broke completely. This PR fixes that.
...Well, mostly. On X11 at least, it's a coin toss if the popup will show properly or if it will disappear immediately. Any help on how to fix that is welcomed.

After investigation on X11 (ArchLinux/Gnome) I found out there's an issue in the popup logic itself (so it's actually different from #50367). There's a boolean popped_up in Popup which is used to avoid closing a popup before it has been focused, when the parent closes. But in some cases it's not reset properly, that's why it randomly fails.
I've opened #50711 to fix this case.
Also, I've tested on Windows and unfortunately this PR is not working properly on that platform. Mouse motion events are received only while the cursor is in the specific window (in this case the popup menu itself) so the case where another menu button is hovered is never triggered. I'm not sure if there could be a different logic that works on all platforms, otherwise this PR might require specific fixes on Windows to make it work.

@pouleyKetchoupp Thanks for the fix! Gonna investigate for another way of implementing this.

Thanks!

authors: YeldhamDev akien-mga pouleyKetchoupp


text:
[Export] Read and ZIP project files in 16K chunks instead of reading the whole file at once.

Read and ZIP files in chunks instead of reading the whole file into the single Vector to avoid Vector limitations (and excessive memory usage).
Fixes #54670

Does this slow down exporting times noticeably? If so, a larger buffer (like 64 KB or 256 KB) could be used.

Does this slow down exporting times noticeably? If so, a larger buffer (like 64 KB or 256 KB) could be used.

I have not noticed any substantial difference between original code and this one with 16 KB, 256 KB and 1 MB buffers. But I guess it might depend on the hardware.
Godot already is using the same code with 16 KB buffer to read and write files to the PCK file.

Thanks!

Cherry-picked for 3.5.

Cherry-picked for 3.4.1.

authors: Calinou akien-mga bruvzg


text:
[3.x] Backport editor type icons

Backport of #57175

When backporting changes, if git cherry-pick -x can't be used as a base to reuse the commit message and author credits, it would be good to add the original author as co-author of the backport commit (with Co-authored-by: FireForge <email> at the end of the commit message, with email sourced from git log).

Thanks!

authors: akien-mga timothyqiu


text:
[Websocket] Remove dummy JS server implemenation.

It does nothing but printing errors (only websocket client is available in browsers), so we might as well return null when you instantiate it.

(rebased on very recent master to be nice on CI)

Cherry-picked for 3.6.

authors: Faless akien-mga


text:
Fix a case in global function highlighting

Ah yeah, the highlighter's need to address unusual syntax you don't normally think about. I missed yet another such detail in #64651
With this PR, global functions are now highlighted as such even if the bracket is a few whitespaces away:

Also tweaked the default color a tiny bit as some users complained it was too dark and hard to read on some themes.

Thanks!

authors: MewPurPur akien-mga


text:
Rename all gdnative occurences to gdextension

I guess it's kind of needed before 4.0.
It at least compiles on my computer, so I don't think there are any rename that caused an issue for now. I hope I did not rename too much, though I checked most changes (translations and 3 to 4 converter renames were removed for example)
It will need a correspondind godot-cpp update though.
Non-exhaustive list of case-sensitive renames:
GDExtension -> GDNative
GDNATIVE -> GDEXTENSION
gdextension -> gdnative
ExtensionExtension ->Extension (for where there was GDNativeExtension)
EXTENSION_EXTENSION ->EXTENSION (for where there was GDNATIVE_EXTENSION)
gdnlib -> gdextension
gdn_interface -> gde_interface
gdni -> gde_interface

Thanks!

authors: akien-mga groud


text:
[Linux] Process TTS callback on the main thread to avoid speech-dispatcher deadlock.

Fixes https://github.com/godotengine/godot/issues/73605

Thanks!

authors: akien-mga bruvzg


text:
Fixing compilation errors for gles3 for Mac OS X

This is so far the first round of changes to get the compilation errors fixed on Mac OS X. More to follow. It compiles but is still broken at this point in time. Some of the fixes are coming from earlier PRs that went into the glew3 branch and didn't make it into the master.
Also there is a temporary fix in here until this issue is fixed upstream:
https://github.com/Dav1dde/glad/issues/70
(hopefully resolved this weekend..)

Ok, we kinda have a working OSX build now. It suffers from the "screen is white until you resize" issue Reduz mentioned was also happening on windows and I've noticed that button clicks are sometimes being ignored. But we've got a starting point!


text:
Display human-readable descriptions for signal types in crash handlers

Follow-up to https://github.com/godotengine/godot/pull/33505 and https://github.com/godotengine/godot/pull/61906.

Previously, only the signal number was displayed:
handle_crash: Program crashed with signal 4

Now, the signal code and description are shown:
handle_crash: Program crashed with signal 4 (SIGILL) - Illegal instruction

This only affects Linux and macOS, not Windows.

Should we add a description for them all?

The signal handler is only registered for SIGSEGV, SIGFPE, and SIGILL, so the other cases are dead anyways.
https://github.com/godotengine/godot/blob/9b3f13dee8c6215f86d2a3f9aabc67d2f7af2950/platform/linuxbsd/crash_handler_linuxbsd.cpp#L189-L193

I don't think we should add more signals to the crash handler, so I think it's best to remove the extra cases I added.

authors: Calinou RedworkDE


text:
Update HTTPRequest Class Documentation

Salvage of https://github.com/godotengine/godot/pull/68640.
Rebased on master, applied the feedback, using [member] instead of [code] for sanity checking and removing the outdated true params in the code examples and fixed the reponse typo while crediting the original author.

Agreed on both counts; applied and squashed.

Thanks!

Cherry-picked for 4.0.4.

authors: YuriSizov mhilbrunner


text:
Fix issue by changing direction for the arrows of one way collisions for 2d collision shapes and polygons

This pull request fixes and closes https://github.com/godotengine/godot/issues/84542.
I am fairly certain that what the issue requests makes sense and is more clear than the current implementation. What was fixed is that in both the files changed, the arrows were reversed by changing the coordinates of line_to(). This felt like the simplest and clearest way of doing it. Now, the arrows show which way an object can pass through the shape/polygon instead of the opposite. Please comment on this if you feel the opposite.

I believe this will now introduce an inconsistency with the tile maps visualisation

See https://github.com/godotengine/godot/issues/84542#issuecomment-1812285185.
If anything, maybe moving/shifting the arrow so it would point in?

Or maybe adding a second green arrow? Although this would probably be too much / too noisy.
For sure currently this PR is confusing for me:

BTW @Wiltof in case of visual changes it's a good idea to showacase before/after in the PR description.

Could we change outline colors for outlines that are non-solid through one side based on their normal (relative to the one-way collision vector)? This may be a good way to resolve ambiguity without having to change the arrow's direction.
Something like this in the example GIF above:

Could we change outline colors for outlines that are non-solid through one side based on their normal (relative to the one-way collision vector)? This may be a good way to resolve ambiguity without having to change the arrow's direction.
Something like this in the example GIF above:

The purple outlines are nonsolid due to the one-way collision vector.

I like this idea, but I would then remove the red arrows completely and just keep the coloured edges indicating which sides are "open" for other objects to pass through. 💡
I actually understand the red arrows the exact other way around: The red arrow should indicate in which direction the "bounce" force pushes... 🤔😆
Especially the right side in your example is confusing for me, as the box doesn't collide with the still one, although it has a red arrow showing upwards. The logic you mention, would mean that the box on the right should only be able to pass from below to top. In the right case therefore, two arrows or an arrow with two ends would be needed...

See #84542 (comment).
If anything, maybe moving/shifting the arrow so it would point in?  Or maybe adding a second green arrow? Although this would probably be too much / too noisy.
For sure currently this PR is confusing for me:
BTW @Wiltof in case of visual changes it's a good idea to showacase before/after in the PR description.

Ah thanks for the feedback, I will keep this in mind
And for sure, I definitely see the way you all think about the issue, and it wasn't my intention to try to come in and screw stuff up if this would create more confusion. At least the PR has created some discussion around the topic, even though if it's in an unintended manner, so sorry for that. Personally though, with exception for the colour, I feel like signifying which way objects can pass through is more intuitive. This doesn't mean that it is necessarily the right way to do it however. I like the idea with the outlines, and can look at amending the PR if that is something that seems to be consensus.

authors: AThousandShips Calinou Daniel-The-Fox Wiltof kleonc


text:
Add PWA option to ensure cross-origin isolation headers on web export

Sister PR to #85939

When the PWA option is enabled, the installed PWA will make sure to enable COEP/COOP request headers if the option is selected.

Converted to draft as this doesn't seem to work, yet.

Attached the 2 patches (001 adds the service worker linting and its config, 002 is just a linter pass).
patch-001.diff.txt
patch-002.diff.txt

There are some "style" changes (e.g. using the loose equality operator) which are not great in JS .

Actually, this was done precisely with that in mind. null is pretty much the exception when using the loose equality operator. (see https://eslint.org/docs/latest/rules/eqeqeq#smart)
You actually want to compare a variable loosely to null. That's because Javascript considers null and undefined nullish (hence both values pass the loose equality test with null), but not the falsy values (eg. "", 0, which do not pass the loose equality test with null). Whence why, instead, we should replace all the !value tests by value != null. (but that's for another PR)
undefined == null; // `true`
"" == null; // `false`

Attached the 2 patches (001 adds the service worker linting and its config, 002 is just a linter pass). patch-001.diff.txt patch-002.diff.txt
EDIT: Remember to git add platform/web/.eslintrc.sw.js

Done!

Rebase done!

Thanks! Great feature to have :)

authors: Faless adamscott akien-mga