text:
[Bullet] Usage of freed memory in BulletPhysicsDirectBodyState::get_contact_collider_id when running project

Godot version:
3.2.4.beta.custom_build. 185520c5b
OS/device including version:
Ubuntu 20.04 GLES 2
Issue description:
When trying to run 1h stress test of The worst Godot test project, then there is 50% chance that it will use freed memory:
 ==11635==ERROR: AddressSanitizer: heap-use-after-free on address 0x613001a71e40 at pc 0x0000029f4e5c bp 0x7ffe9536dbd0 sp 0x7ffe9536dbc0
READ of size 8 at 0x613001a71e40 thread T0
    #0 0x29f4e5b in BulletPhysicsDirectBodyState::get_contact_collider_id(int) const modules/bullet/rigid_body_bullet.cpp:178
    #1 0xaac7353 in RigidBody::_direct_state_changed(Object*) scene/3d/physics_body.cpp:489
    #2 0x17afe4b in MethodBind1<Object*>::call(Object*, Variant const**, int, Variant::CallError&) core/method_bind.gen.inc:775
    #3 0xe8d6280 in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:919
    #4 0x2a0017b in RigidBodyBullet::dispatch_callbacks() modules/bullet/rigid_body_bullet.cpp:376
    #5 0x2aacafb in SpaceBullet::flush_queries() modules/bullet/space_bullet.cpp:375
    #6 0x2ab6c0c in onBulletPreTickCallback(btDynamicsWorld*, float) modules/bullet/space_bullet.cpp:566
    #7 0x387c945 in btDiscreteDynamicsWorld::internalSingleStepSimulation(float) thirdparty/bullet/BulletDynamics/Dynamics/btDiscreteDynamicsWorld.cpp:458
    #8 0x3a50bc1 in btSoftRigidDynamicsWorld::internalSingleStepSimulation(float) thirdparty/bullet/BulletSoftBody/btSoftRigidDynamicsWorld.cpp:88
    #9 0x387bfdd in btDiscreteDynamicsWorld::stepSimulation(float, int, float) thirdparty/bullet/BulletDynamics/Dynamics/btDiscreteDynamicsWorld.cpp:434
    #10 0x2aad198 in SpaceBullet::step(float) modules/bullet/space_bullet.cpp:381
    #11 0x297d950 in BulletPhysicsServer::step(float) modules/bullet/bullet_physics_server.cpp:1567
    #12 0x153c018 in Main::iteration() main/main.cpp:2087
    #13 0x142dcd9 in OS_X11::run() platform/x11/os_x11.cpp:3608
    #14 0x139ab39 in main platform/x11/godot_x11.cpp:56
    #15 0x7fb5126ae0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    #16 0x139a74d in _start (/home/runner/work/The-worst-Godot-test-project/The-worst-Godot-test-project/godot.x11.tools.64s+0x139a74d)

0x613001a71e40 is located 0 bytes inside of 344-byte region [0x613001a71e40,0x613001a71f98)
freed by thread T0 here:
    #0 0x7fb513bd4025 in operator delete(void*, unsigned long) (/lib/x86_64-linux-gnu/libasan.so.5+0x111025)
    #1 0x29fc1e2 in RigidBodyBullet::~RigidBodyBullet() modules/bullet/rigid_body_bullet.cpp:309
    #2 0x297b235 in BulletPhysicsServer::free(RID) modules/bullet/bullet_physics_server.cpp:1511
    #3 0x2b2ca33 in CSGShape::set_use_collision(bool) modules/csg/csg_shape.cpp:55
    #4 0x1eb818b in MethodBind1<bool>::call(Object*, Variant const**, int, Variant::CallError&) core/method_bind.gen.inc:775
    #5 0xe8d6280 in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:919
    #6 0xeb58bcf in Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) core/variant_call.cpp:1129
    #7 0x19fa38d in GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Variant::CallError&, GDScriptFunction::CallState*) modules/gdscript/gdscript_function.cpp:1091
    #8 0x1826e65 in GDScriptInstance::call(StringName const&, Variant const**, int, Variant::CallError&) modules/gdscript/gdscript.cpp:1238
    #9 0xe8d5ded in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:898
    #10 0xeb58bcf in Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) core/variant_call.cpp:1129
    #11 0x19fa38d in GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Variant::CallError&, GDScriptFunction::CallState*) modules/gdscript/gdscript_function.cpp:1091
    #12 0x1826e65 in GDScriptInstance::call(StringName const&, Variant const**, int, Variant::CallError&) modules/gdscript/gdscript.cpp:1238
    #13 0xe8d5ded in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:898
    #14 0xeb58bcf in Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) core/variant_call.cpp:1129
    #15 0x19fa38d in GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Variant::CallError&, GDScriptFunction::CallState*) modules/gdscript/gdscript_function.cpp:1091
    #16 0x1826e65 in GDScriptInstance::call(StringName const&, Variant const**, int, Variant::CallError&) modules/gdscript/gdscript.cpp:1238
    #17 0xe8d5ded in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:898
    #18 0xeb58bcf in Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) core/variant_call.cpp:1129
    #19 0x19fa38d in GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Variant::CallError&, GDScriptFunction::CallState*) modules/gdscript/gdscript_function.cpp:1091
    #20 0x182737b in GDScriptInstance::call_multilevel(StringName const&, Variant const**, int) modules/gdscript/gdscript.cpp:1254
    #21 0x95127fa in Node::_notification(int) scene/main/node.cpp:69
    #22 0x16d94eb in Node::_notificationv(int, bool) scene/main/node.h:46
    #23 0x1703b47 in Spatial::_notificationv(int, bool) scene/3d/spatial.h:54
    #24 0xe8d671c in Object::notification(int, bool) core/object.cpp:929
    #25 0x9640adb in SceneTree::_notify_group_pause(StringName const&, int) scene/main/scene_tree.cpp:985
    #26 0x962eb69 in SceneTree::iteration(float) scene/main/scene_tree.cpp:481
    #27 0x153be15 in Main::iteration() main/main.cpp:2080
    #28 0x142dcd9 in OS_X11::run() platform/x11/os_x11.cpp:3608
    #29 0x139ab39 in main platform/x11/godot_x11.cpp:56

previously allocated by thread T0 here:
    #0 0x7fb513bd2947 in operator new(unsigned long) (/lib/x86_64-linux-gnu/libasan.so.5+0x10f947)
    #1 0x294d1e2 in BulletPhysicsServer::body_create(PhysicsServer::BodyMode, bool) modules/bullet/bullet_physics_server.cpp:454
    #2 0x2b2a998 in CSGShape::set_use_collision(bool) modules/csg/csg_shape.cpp:46
    #3 0x1eb818b in MethodBind1<bool>::call(Object*, Variant const**, int, Variant::CallError&) core/method_bind.gen.inc:775
    #4 0xe8d6280 in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:919
    #5 0xeb58bcf in Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) core/variant_call.cpp:1129
    #6 0x19fa38d in GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Variant::CallError&, GDScriptFunction::CallState*) modules/gdscript/gdscript_function.cpp:1091
    #7 0x1826e65 in GDScriptInstance::call(StringName const&, Variant const**, int, Variant::CallError&) modules/gdscript/gdscript.cpp:1238
    #8 0xe8d5ded in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:898
    #9 0xeb58bcf in Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) core/variant_call.cpp:1129
    #10 0x19fa38d in GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Variant::CallError&, GDScriptFunction::CallState*) modules/gdscript/gdscript_function.cpp:1091
    #11 0x1826e65 in GDScriptInstance::call(StringName const&, Variant const**, int, Variant::CallError&) modules/gdscript/gdscript.cpp:1238
    #12 0xe8d5ded in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:898
    #13 0xeb58bcf in Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) core/variant_call.cpp:1129
    #14 0x19fa38d in GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Variant::CallError&, GDScriptFunction::CallState*) modules/gdscript/gdscript_function.cpp:1091
    #15 0x1826e65 in GDScriptInstance::call(StringName const&, Variant const**, int, Variant::CallError&) modules/gdscript/gdscript.cpp:1238
    #16 0xe8d5ded in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:898
    #17 0xeb58bcf in Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) core/variant_call.cpp:1129
    #18 0x19fa38d in GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Variant::CallError&, GDScriptFunction::CallState*) modules/gdscript/gdscript_function.cpp:1091
    #19 0x182737b in GDScriptInstance::call_multilevel(StringName const&, Variant const**, int) modules/gdscript/gdscript.cpp:1254
    #20 0x951220d in Node::_notification(int) scene/main/node.cpp:60
    #21 0x16d94eb in Node::_notificationv(int, bool) scene/main/node.h:46
    #22 0x1703b47 in Spatial::_notificationv(int, bool) scene/3d/spatial.h:54
    #23 0xe8d671c in Object::notification(int, bool) core/object.cpp:929
    #24 0x9640adb in SceneTree::_notify_group_pause(StringName const&, int) scene/main/scene_tree.cpp:985
    #25 0x9631184 in SceneTree::idle(float) scene/main/scene_tree.cpp:525
    #26 0x153d24c in Main::iteration() main/main.cpp:2103
    #27 0x142dcd9 in OS_X11::run() platform/x11/os_x11.cpp:3608
    #28 0x139ab39 in main platform/x11/godot_x11.cpp:56
    #29 0x7fb5126ae0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

SUMMARY: AddressSanitizer: heap-use-after-free modules/bullet/rigid_body_bullet.cpp:178 in BulletPhysicsDirectBodyState::get_contact_collider_id(int) const

https://github.com/qarmin/The-worst-Godot-test-project/runs/1498789843?check_suite_focus=true
Steps to reproduce:

Run minimal project with sanitizers support

CI details - https://github.com/qarmin/The-worst-Godot-test-project/blob/3.2/.github/workflows/linux_builds_1.yml
Minimal reproduction project:
https://github.com/qarmin/The-worst-Godot-test-project/tree/3.2
I know that project is really big but for now I'm unable to create smaller

Can't reproduce this anymore


text:
Android Application Bundles (aab) not exporting correctly for Mono projects

Godot version:
3.3 (Mono)
OS/device including version:
Win 10 exporting to Android 11
Issue description:
After exporting a Mono app using the AAB support added in 3.3, the app will successfully export but will crash on the device.
System.DllNotFoundException: __Internal assembly:<unknown assembly> type:<unknown type> member:(null)
   at (wrapper managed-to-native) System.TimeZoneInfo+AndroidTimeZones.monodroid_get_system_property(string,intptr&)
   at System.TimeZoneInfo+AndroidTimeZones.GetDefaultTimeZoneName () [0x00029] in <a947100bfc9e4b689622af54e1e07934>:0
   at System.TimeZoneInfo+AndroidTimeZones.get_Local () [0x00000] in <a947100bfc9e4b689622af54e1e07934>:0
   at System.TimeZoneInfo.CreateLocal () [0x00000] in <a947100bfc9e4b689622af54e1e07934>:0
   at System.TimeZoneInfo.get_Local () [0x00009] in <a947100bfc9e4b689622af54e1e07934>:0
   at System.TimeZoneInfo.ConvertTimeToUtc (System.DateTime dateTime, System.TimeZoneInfoOptions flags) [0x00000] in <a947100bfc9e4b689622af54e1e07934>:0
   at System.DateTime.ToUniversalTime () [0x00000] in <a947100bfc9e4b689622af54e1e07934>:0

The same project exported as an APK does not crash, and runs as expected.
I suspect whether or not you hit this exception depends on which bits of Mono you are using in your project. Some API calls seem to be linked correctly, and some do not.
I'm unsure if related to this earlier issue https://github.com/godotengine/godot/issues/33851 - but they share the same error message.
Steps to reproduce:

Call a method that invokes something in monodroid - e.g. DateTime.ToUniversalTime()
Export application as APK and run on device - it should work as expected.
Export application as AAB and run on device (e.g. via bundletool, or via Play Store) - it will crash.

Minimal reproduction project:
Testing-AndroidAABLinking.zip

I can confirm that this issue still exists in Godot.3.3.4.mono
--------- beginning of crash
2021-12-01 13:13:00.942 7285-7398/? A/libc: FORTIFY: pthread_mutex_lock called on a destroyed mutex (0xc17ed80c)
2021-12-01 13:13:00.946 7285-7398/? A/libc: Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 7398 (Thread Pool Wor), pid 7285 (icopo.SpaceFire)
2021-12-01 13:13:00.939 7285-7342/? E/mono: Unhandled Exception:
    System.DllNotFoundException: __Internal assembly:<unknown assembly> type:<unknown type> member:(null)
        at (wrapper managed-to-native) System.TimeZoneInfo+AndroidTimeZones.monodroid_get_system_property(string,intptr&)
      at System.TimeZoneInfo+AndroidTimeZones.GetDefaultTimeZoneName () [0x00029] in <a947100bfc9e4b689622af54e1e07934>:0
      at System.TimeZoneInfo+AndroidTimeZones.get_Local () [0x00000] in <a947100bfc9e4b689622af54e1e07934>:0
      at System.TimeZoneInfo.CreateLocal () [0x00000] in <a947100bfc9e4b689622af54e1e07934>:0
      at System.TimeZoneInfo.get_Local () [0x00009] in <a947100bfc9e4b689622af54e1e07934>:0
      at System.TimeZoneInfo.GetDateTimeNowUtcOffsetFromUtc (System.DateTime time, System.Boolean& isAmbiguousLocalDst) [0x00000] in <a947100bfc9e4b689622af54e1e07934>:0
      at System.DateTime.get_Now () [0x00008] in <a947100bfc9e4b689622af54e1e07934>:0
      at System.Timers.Timer.MyTimerCallback (System.Object state) [0x00019] in <ff8dc755b313498597c01f2c3444935b>:0
      at System.Threading.Timer+Scheduler.TimerCB (System.Object o) [0x00007] in <a947100bfc9e4b689622af54e1e07934>:0
      at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () [0x00008] in <a947100bfc9e4b689622af54e1e07934>:0
      at System.Threading.ThreadPoolWorkQueue.Dispatch () [0x00074] in <a947100bfc9e4b689622af54e1e07934>:0
      at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () [0x00000] in <a947100bfc9e4b689622af54e1e07934>:0

@andy-noisyduck did you find any way around this issue ?
i have tested it on Godot_3.4.mono and i got the same result , still crashing .

I have opened this issue https://github.com/godotengine/godot/issues/55638 , It seems that this issue is related to using System.Timers in general

source: gharchive/issue

authors: MrZak-dev andy-noisyduck

repo: godotengine/godot

license: MIT

license_type: permissive

license_source: github-api


text:
Object::get_property_list don't include script variables in References

Issue description:
The function Object::get_property_list don't include export and normal script variables, on GDScript classes that extends directly from Reference. The same seems to happens on classes that inherit from Object. But for example when the script extends from Resource the function works normally.
Steps to reproduce:

Run the example project.
Press the "Reference" button (Empty output).
Press the "Resource" button, the variables appears on the output, event if the only difference between the two scripts is the inheritance.

Link to minimal example project:
reference_property.zip

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

Checking the Object source code looks like there's a virtual function Object::_use_builtin_script(It's overriden in Node and Resource classes to return true), called in Object::get_property_list to determine if property list will have or not the script data.
IMO the best solution for this issue is reverse the order of the property list in Object::_get_property_list_bind.

the _use_builtin_script function should be removed, but it will break the many property editors around the editor. This is an ancient hack that makes no more sense now. Will tag for 3.0 so we can safely remove it there

this was implemented in 3.0

authors: TheHX Zylann reduz


text:
MultiMesh emits Condition "uniform.get_id_count() != 1" is true. error at creation

Godot version
Godot 4.0 alpha 7
System information
Windows 10
Issue description
The following code:
extends Node3D

# GrassGenerator.gd

@export var width : int = 512
@export var height : int = 512
@export var subdivisions : int = 20
@export var grass_mesh : Mesh
@export_range(1.0, 10.0) var n = 2.0

var generated = false

func generate():
	if generated:
		return
	var ns := NoiseTexture.new()
	ns.width = width
	ns.height = height
	ns.noise = FastNoiseLite.new()
	await ns.changed

	var image : Image = ns.get_image()
	var img_chunk_size = Vector2(width, height) / subdivisions
	var half = Vector2(width, height) / 2
	var grass_mat = preload("res://materials/grass.material")
	var chunk_size = Vector3(img_chunk_size.x, 0, img_chunk_size.y) / n

	for x in range(subdivisions):
		for y in range(subdivisions):
			var mp = Vector3(x, 0, y) * chunk_size - Vector3(half.x, 0, half.y) / n
			var transforms = []
			for sx in range(img_chunk_size.x):
				for sy in range(img_chunk_size.y):
					var v = Vector2(x * img_chunk_size.x + sx, y * img_chunk_size.y + sy)
					var amount = image.get_pixel(v.x, v.y).r
					if amount > 0.5:
						var p = Vector3(sx, 0, sy)
						p /= n
						p += Vector3(randf_range(-0.5, 0.5), 0, randf_range(-0.5, 0.5))
						var random_scale = randf_range(2.0, 3.5)
						var random_height = randf_range(0.0, 3.0)
						var t = Transform3D(Basis(Vector3(0, 1, 0), randf_range(-PI, PI)).scaled(Vector3(random_scale, random_scale + random_height, random_scale)), p)

						transforms.push_back(t)

			var mmi := MultiMeshInstance3D.new()
			mmi.material_override = grass_mat
			mmi.position = mp
			mmi.visibility_range_end = 100
			mmi.visibility_range_begin_margin = 1.0
			mmi.visibility_range_fade_mode = GeometryInstance3D.VISIBILITY_RANGE_FADE_SELF

			var mm := MultiMesh.new()
			mm.transform_format = MultiMesh.TRANSFORM_3D
			mm.instance_count = transforms.size()
			mm.mesh = grass_mesh

			var i = 0
			for t in transforms:
				mm.set_instance_transform(i, t)
				i+=1
			mmi.multimesh = mm
			add_child(mmi)
	generated = true

func _ready() -> void:
	if visible:
		generate()
	else:
		connect(&"visibility_changed", generate)

is creating successfully but generate errors

Not sure why it's happening, probably MultiMesh resource need to take step to be properly initialized.
Steps to reproduce
Just run the demo project
Minimal reproduction project
MMBug.zip

The code generates some MultiMeshes objects with zero instances. As they have zero instances their buffer has no valid RID to create uniform which results in these errors.

authors: Chaosus MightiestGoat


text:
WebGL: Basis Universal textures are rendered as black

Godot version
4.0.dev (dcb3754)
System information
Windows 11, Chrome 108.0.5359.125 (Official Build), GeForce RTX3080 (driver 527.56)
Issue description
When exporting WebGL build, the materials using Basis Universal textures are rendered as black.
May be same issue as #67558.
Intended (VRAM Compressed texture):

Reproduced (Basis Universal texture):

Steps to reproduce

Open attached minimal reproduction project.
Export for Web.
Run in Chrome.

Minimal reproduction project
basis_universal_rendered_as_black.zip

One of the output formats supported by Basis Universal is ETC2, which is supported in WebGL 2.0. Therefore, it should be feasible to make it work in theory.

It shows error message failed! on level 0 in console of chrome developer tools.
Also, when I call basis_universal_unpacker_ptr with a PackedByteArray of .basis file prefixed with BASIS_DECOMPRESS_RGB as following, it shows same error failed! on level 0.
// image.h
	Error load_basis_from_buffer(const Vector<uint8_t> &p_array);

// image.cpp
Error Image::load_basis_from_buffer(const Vector<uint8_t> &p_array) {
	ERR_FAIL_NULL_V_MSG(
			basis_universal_unpacker_ptr,
			ERR_UNAVAILABLE,
			"The Basis module isn't enabled. Recompile the Godot editor or export template binary with the `module_basis_universal_enabled=yes` SCons option.");
	return _load_from_buffer(p_array, basis_universal_unpacker_ptr);
}

void Image::_bind_methods() {
...
	ClassDB::bind_method(D_METHOD("load_basis_from_buffer", "buffer"), &Image::load_basis_from_buffer);
...
}

func _on_http_request_request_completed(result: int, response_code: int, _headers: PackedStringArray, body: PackedByteArray):
	if result != HTTPRequest.RESULT_SUCCESS:
		push_error("HTTP request failure: ", response_code)
		return

	# push BASIS_DECOMPRESS_RGB to front
	for _i in range(4):
		body.insert(0, 0)
	body.encode_u32(0, 1)

	var image := Image.create(256, 256, true, Image.FORMAT_DXT5)
	image.load_basis_from_buffer(body)
	$MeshInstance3D.mesh.surface_get_material(0).albedo_texture = ImageTexture.create_from_image(image)

One of the output formats supported by Basis Universal is ETC2, which is supported in WebGL 2.0. Therefore, it should be feasible to make it work in theory.

ETC/PVRTC/ASTC on WebGL is not supported by Chromium and Firefox on Windows. (Sadly, regardless of GPU driver's support)
https://toji.github.io/texture-tester/
(If the current implement is ETC2 premise) The smarter decoding process is to change the transcoding format to match the capability of the browser. (regardless of the OS)

On Windows Chrome, requested format to transcode is basist::transcoder_texture_format::cTFBC7_M6_OPAQUE_ONLY.
That worked fine with my PR on Chrome, but we should check for other browsers and OS.

ETC/PVRTC/ATC on WebGL is not supported by Chromium and Firefox on Windows. (Sadly, regardless of GPU driver's support)

That test only tests for ETC1, not ETC2.

authors: Calinou TyounanMOTI Yasei-no-otoko


text:
Connection doesn't keep alive the reference its connected to

Godot version
3.5.1.stable.mono
System information
Linux, Pop_OS! 22.04
Issue description
If you attempt to connect a signal to function in a reference class, it might get freed (probably, because it doesn't increase its refcount). I'd argue that being connected to, counts as being "in use", and the reference should be freed only after the connection is no longer valid (i.e, when the emitter object is freed).
Steps to reproduce

Run the following code

extends Node

class Ref:
    func f():
        print("F was called")

func _ready():
    var reference = Ref.new()
    get_tree().create_timer(1).connect("timeout", reference, "f")
    monitor(weakref(reference))

func monitor(weak_ref):
    while true:
        if not weak_ref.get_ref():
            print("Reference was deleted")
            return
        yield(get_tree(), "idle_frame")`

Expected output would be F was called; Reference was deleted after 1 second. The actual output is Reference was deleted immediately (pretty much) after the script starts.

Minimal reproduction project
N/A

Connection keep object as a pointer and don't increase its reference count. We could either document it or apply a similar fix as #70795.

authors: KoBeWi shelerr


text:
Infinite recursion in SceneState::instantiate -> PackedScene::instantiate

Godot version
v4.0.beta.custom_build [f15ae5fd4]
System information
Windows 10, Forward+
Issue description
When I create an instance of a .blend file, sometimes Godot crashes with infinite recursion.
 	godot.windows.editor.x86_64.exe!SceneState::instantiate(SceneState::GenEditState p_edit_state) Line 106	C++
 	godot.windows.editor.x86_64.exe!PackedScene::instantiate(PackedScene::GenEditState p_edit_state) Line 1820	C++
 	godot.windows.editor.x86_64.exe!SceneState::instantiate(SceneState::GenEditState p_edit_state) Line 144	C++
 	godot.windows.editor.x86_64.exe!PackedScene::instantiate(PackedScene::GenEditState p_edit_state) Line 1820	C++
 	godot.windows.editor.x86_64.exe!SceneState::instantiate(SceneState::GenEditState p_edit_state) Line 144	C++
 	godot.windows.editor.x86_64.exe!PackedScene::instantiate(PackedScene::GenEditState p_edit_state) Line 1820	C++
 	godot.windows.editor.x86_64.exe!SceneState::instantiate(SceneState::GenEditState p_edit_state) Line 144	C++
 	godot.windows.editor.x86_64.exe!PackedScene::instantiate(PackedScene::GenEditState p_edit_state) Line 1820	C++
...

This is the specific line it crashed on: Node **ret_nodes = (Node **)alloca(sizeof(Node *) * nc);

Node *PackedScene::instantiate(GenEditState p_edit_state) const {
#ifndef TOOLS_ENABLED
	ERR_FAIL_COND_V_MSG(p_edit_state != GEN_EDIT_STATE_DISABLED, nullptr, "Edit state is only for editors, does not work without tools compiled.");
#endif

	Node *s = state->instantiate((SceneState::GenEditState)p_edit_state);

then the scene state calls back to the packed scene instatiate here:
Node *SceneState::instantiate(GenEditState p_edit_state) const {
...
		if (i == 0 && base_scene_idx >= 0) {
			//scene inheritance on root node
			Ref<PackedScene> sdata = props[base_scene_idx];
			ERR_FAIL_COND_V(!sdata.is_valid(), nullptr);
			node = sdata->instantiate(p_edit_state == GEN_EDIT_STATE_DISABLED ? PackedScene::GEN_EDIT_STATE_DISABLED : PackedScene::GEN_EDIT_STATE_INSTANCE); //only main gets main edit state

Steps to reproduce
Right-click on the blend file below:
"New Inherited Scene"
Ctrl-S, note that it tries to save over the .blend file.
Scene|Save scene as - save as "revolver_test" or whatever.
Try adding a material -- sometimes it crashes here
If not, create a new scene, then drag and drop the "revolver_test" scene into the new scene.  This usually crashes it.
Minimal reproduction project
revolutionary_revolver.zip

Actually, this may already be fixed.  I just tried beta 17 and it didn't exhibit the behavior where if you try to save an inherited scene, it will attempt to save over the existing scene, so I wasn't able to follow my repro steps and make it crash.  Guess I'll sync up and see if I can get it to crash in my own custom build again.


text:
cannot change visibility of child node if parent node is hidden

Operating system or device - Godot version:
Godot 2.1.1
Issue description (what happened, and what was expected):
When you are trying to use the eye icon in the hierarchy to change the visibility of a node that is a child of an invisible node you get an error message saying "This item cannot be made visible because the parent is hidden. Unhide the parent first.".
It's fine that there is a warning for people who would wonder why there are no visible changes, but it should be possible to change the value nevertheless. E.g. I might have a complex scene with two states in it of which one is always hidden. It should be possible to switch those states without having to unhide the root node first.
Apart from that changing the Visible-Flag in the CanvasItem section of the inspector works, but doesn't update the eye-symbol in the hierarchy.
Steps to reproduce:
Create a new scene.
Create a root node of type Node2D.
Create a child node of type Node2D.
Hide the root node.
a) Try to hide the child node.
b) Unset the Visible-flag in the inspector.

@volzhs This looks great!

This is another version. (not done yet)
@bojidar-bg WDYT on this?

@volzhs Well, I think the first one is better, since the gray color is nicer than the red.

@bojidar-bg agreed with colors. I'll make another commit with first one for now. :)

Great solution! I agree about the colors. Grey suggests inactive, red invalid.

I was trying to show grouping colors but it was not easy :(

authors: Warlaan bojidar-bg volzhs


text:
Some Editor-Shortcuts commands don't work in godot 4

Godot version
4
System information
Windows
Issue description
For example I can't call this command with a shortcut

In godot 3 it opens docs for edited object class
Steps to reproduce
try to set a shortcut to Open Documentation command (from Editor-Shortcuts), then open Inspector and press the shortcut. It does nothing for me
Minimal reproduction project

Unable to reproduce it in following versions:
v4.0.2.stable.official [7a0977ce2]
v4.1.dev.custom_build [bd1bc68ba]
Screencast from the latest:


text:
WebGL GLES2 accessing DEPTH_TEXTURE disables shader and shows error in browser about feedback loop.

Godot version
v3.5.2.stable.official [170ba337a]
System information
macOS/Windows 10 in Chrome
Issue description
I have project with problem with DEPTH_TEXTURE when exporting to WebGL.
Trying to work with DEPTH_TEXTURE breaks shader in browser.
Tested in Chrome on macOS and Windows 10
Error in browser (macOS/Windows 10 Chrome)
[.WebGL-0x11c04708e00] GL_INVALID_OPERATION: Feedback loop formed between Framebuffer and active Texture.
I did not see any warnings or errors in Godot telling me that I can't use DEPTH_TEXTURE in GLES2 (like sampler2DArray error) so I assume it's possible to work with it in browser and it's a bug.
If workaround is possible could anyone tell me about it? Trying to create water shader with DEPTH_TEXTURE for more pleasant look and can't think how to overcome this issue.
Steps to reproduce

Create simple project with several objects
Write simple shader and add line where you access DEPTH_TEXTURE, attach it to shadermaterial to one of the objects.
Test webgl export by running server from editor
See errors in console and that object with shadermaterial is not showing
Disable line with accessing DEPTH_TEXTURE
See no errors in console

Minimal reproduction project
depth_texture_webgl_repro.zip

Duplicate of https://github.com/godotengine/godot/issues/46883
This was actually fixed recently in https://github.com/godotengine/godot/pull/80481
The fix will be available in the upcoming 3.6 release

@clayjohn is there way to obtain 3.6 beta 3 HTML export template? Wanted to check it out.

@clayjohn is there way to obtain 3.6 beta 3 HTML export template? Wanted to check it out.

You can download the HTML export template from the link provided in the 3.6 beta 3 blog post https://godotengine.org/article/dev-snapshot-godot-3-6-beta-3/#downloads
That being said, the fix was just merged, and so won't be available until we reach beta 4

@clayjohn ok, understood. Waiting for beta 4 then. Thanks!

authors: clayjohn idchlife


text:
Lightmap artifacts around geometry edges.

Godot version
v4.2.dev.custom_build [19890614c]
System information
Godot v4.2.dev (19890614c) - Windows 10.0.22621 - Vulkan (Forward+) - dedicated AMD Radeon RX 6700 XT (Advanced Micro Devices, Inc.; 27.20.21034.37) - AMD Ryzen 7 5700X 8-Core Processor (16 Threads)
Issue description
I've been poking at @DarioSamo's JNLM denoiser for the past few days and I've been noticing these strange artifacts around the edge of lightmaps not present pre-JNLM:

I also may have identified a fix: accounting for the half-pixel offset added in 2c125bf9c0fa870c5af9a753a6b85295f01f0728 in the JNLM denoiser. I took a look at https://github.com/godotengine/godot/pull/81872 recently and tried reverting it on a guess, and the artifacts disappears completely (see below). Of course, it also unfixes the issue it solved, so reverting it isn't the right fix.
Lightmap with 2c125bf9c0fa870c5af9a753a6b85295f01f0728 reverted, for comparison:

Steps to reproduce
I have been unable to accurately reproduce the problem, but I've identified a (freely available) model that can trigger the issue (MRP).

Open MRP
Bake lightmap
Artifacts can be seen throughout the scene.

Minimal reproduction project
lightmap_seams.zip

I think I noticed this and have a couple of theories as to the probable causes, but I'm surprised the half pixel offset has such an effect. Let's experiment for a bit as this should be easily traceable.

reverting the denoiser

If push comes to shove, we can always drop an if into the half-pixel offset parts. Not that it's the best fix, though.

Seems like it has to do with the fact the noisy pixels don't have a valid normal or position whatsoever, so they don't get denoised. I'm confused as to how exactly the pixel is getting lighting in the first place under those conditions but that explains it.

It's not related to the denoiser. I turned it off and forced it to set all invalid pixels to this green color. I think the noise you're seeing is from previous bakes (will need to check if the texture is getting cleared as it should).

I think the noise you're seeing is from previous bakes (will need to check if the texture is getting cleared as it should).

I nuked the light data (*.lmbake and *.exr) before baking. No joy.

Okay I think I figured it out.
The invalid data came from the dilate step. I'm not sure how it landed there, but there's a dilate step before the denoising, which means it just expands a bunch of noise.
The dilate is required for the seams at the edges of the UV2.
Can you test the commit in this branch and see if it fixes the problem? It did at least for me.
https://github.com/DarioSamo/godot/tree/no-dilate-before-denoise

It seem to have fixed the issue for me, too

authors: DarioSamo atirut-w


text:
Random swap chain errors

Tested versions
Godot 4.3.dev https://github.com/godotengine/godot/commit/2e7fc81315bfa8d0a15f60adff2a12b6f3104236
Forward+ Renderer
System information
Godot v4.3.dev - Windows 10.0.19045 - Vulkan (Forward+) - dedicated AMD Radeon RX 6900 XT (Advanced Micro Devices, Inc.; 31.0.24002.92) - AMD Ryzen 9 5900X 12-Core Processor (24 Threads)
Newest AMD drivers (24.1.1)
Issue description
Not sure why, but I get a lot of swapchain errors with the current master.
May or may not be one time error, I still thought it might be worth reporting.
- Unable to resize the new swap chain.
- A swap chain was not created for the screen.
- Screen was never created.

Steps to reproduce
Open/Use Godot.
Minimal reproduction project (MRP)
Just create a fresh project.

Same here.
Nothing fancy is done with the editor to get stuck. It's just a matter of usage time. It never crashes but the editor goes 'stuck' on a strange popup I can't interact with (only the frame appear, I'm suspecting that's the 'save changes' confirm dialog while the editor wanted to exit, due to the crash).
Godot Engine v4.3.dev.custom_build.25c0433d5 (2024-03-23 21:48:12 UTC) - https://godotengine.org
Vulkan 1.3.277 - Forward+ - Using Device #0: NVIDIA - NVIDIA GeForce RTX 3070 Ti

Operating System:         Linux-x86_64
NVIDIA Driver Version:    550.54.14
NVML Version:             12.550.54.14

Server Version Number:    11.0
Server Vendor String:     The X.Org Foundation
Server Vendor Version:    1.20.13 (12013000)
NV-CONTROL Version:       1.29
Screens:                  1

Here are some logs godot-editor-run-0.log
It contains a session of editor usage with many (sub) "run" project.
I can provide more detailed 'debug' information as I used a locally built version. Just give me what option to put on scons (debug ? other stuff I don't know ?)
Regards.


text:
Crash on folder capitalization change

Tested versions

Reproducible in 4.3-dev6

System information
Windows 11, geForce 4080, Godot 4.3-dev6, Forward+
Issue description
Changing the capitalization of an empty folder crashes Godot.
Steps to reproduce
I started on a blank, fresh project.

Created a folder named 'OneSHots'
Right click - rename to 'OneShots'
Godot crashes.

Minimal reproduction project (MRP)
N/A

CrashHandlerException: Program crashed
Engine version: Godot Engine v4.3.dev.custom_build (7cdad333114e6765351ed0facb48db228ef29b7b)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[0] CowData<EditorFileSystemDirectory::FileInfo *>::_get_size (C:\godot_source\core\templates\cowdata.h:128)
[1] CowData<EditorFileSystemDirectory::FileInfo *>::size (C:\godot_source\core\templates\cowdata.h:181)
[2] Vector<EditorFileSystemDirectory::FileInfo *>::size (C:\godot_source\core\templates\vector.h:94)
[3] EditorFileSystemDirectory::get_file_count (C:\godot_source\editor\editor_file_system.cpp:88)
[4] FileSystemDock::_before_move (C:\godot_source\editor\filesystem_dock.cpp:2015)
[5] FileSystemDock::_rename_operation_confirm (C:\godot_source\editor\filesystem_dock.cpp:1843)
[6] call_with_variant_args_helper<FileSystemDock> (C:\godot_source\core\variant\binder_common.h:309)
[7] call_with_variant_args<FileSystemDock> (C:\godot_source\core\variant\binder_common.h:419)
[8] CallableCustomMethodPointer<FileSystemDock>::call (C:\godot_source\core\object\callable_method_pointer.h:104)
[9] Callable::callp (C:\godot_source\core\variant\callable.cpp:58)
[10] Object::emit_signalp (C:\godot_source\core\object\object.cpp:1221)
[11] Node::emit_signalp (C:\godot_source\scene\main\node.cpp:3903)
[12] Object::emit_signal<> (C:\godot_source\core\object\object.h:936)
[13] Tree::item_edited (C:\godot_source\scene\gui\tree.cpp:4469)
[14] Tree::_line_editor_submit (C:\godot_source\scene\gui\tree.cpp:3244)
[15] call_with_variant_args_helper<Tree,String,0> (C:\godot_source\core\variant\binder_common.h:309)
[16] call_with_variant_args<Tree,String> (C:\godot_source\core\variant\binder_common.h:419)
[17] CallableCustomMethodPointer<Tree,String>::call (C:\godot_source\core\object\callable_method_pointer.h:104)
[18] Callable::callp (C:\godot_source\core\variant\callable.cpp:58)
[19] Object::emit_signalp (C:\godot_source\core\object\object.cpp:1221)
[20] Node::emit_signalp (C:\godot_source\scene\main\node.cpp:3903)
[21] Object::emit_signal<String> (C:\godot_source\core\object\object.h:936)
[22] LineEdit::gui_input (C:\godot_source\scene\gui\line_edit.cpp:503)
[23] Control::_call_gui_input (C:\godot_source\scene\gui\control.cpp:1813)
[24] Viewport::_gui_input_event (C:\godot_source\scene\main\viewport.cpp:2201)
[25] Viewport::push_input (C:\godot_source\scene\main\viewport.cpp:3250)
[26] Window::_window_input (C:\godot_source\scene\main\window.cpp:1631)
[27] call_with_variant_args_helper<Window,Ref<InputEvent> const &,0> (C:\godot_source\core\variant\binder_common.h:304)
[28] call_with_variant_args<Window,Ref<InputEvent> const &> (C:\godot_source\core\variant\binder_common.h:419)
[29] CallableCustomMethodPointer<Window,Ref<InputEvent> const &>::call (C:\godot_source\core\object\callable_method_pointer.h:104)
[30] Callable::callp (C:\godot_source\core\variant\callable.cpp:58)
[31] Callable::call<Ref<InputEvent> > (C:\godot_source\core\variant\variant.h:873)
[32] DisplayServerWindows::_dispatch_input_event (C:\godot_source\platform\windows\display_server_windows.cpp:3482)
[33] DisplayServerWindows::_dispatch_input_events (C:\godot_source\platform\windows\display_server_windows.cpp:3467)
[34] Input::_parse_input_event_impl (C:\godot_source\core\input\input.cpp:774)
[35] Input::flush_buffered_events (C:\godot_source\core\input\input.cpp:1045)
[36] DisplayServerWindows::process_events (C:\godot_source\platform\windows\display_server_windows.cpp:2982)
[37] OS_Windows::run (C:\godot_source\platform\windows\os_windows.cpp:1686)
[38] widechar_main (C:\godot_source\platform\windows\godot_windows.cpp:181)
[39] _main (C:\godot_source\platform\windows\godot_windows.cpp:206)
[40] main (C:\godot_source\platform\windows\godot_windows.cpp:220)
[41] WinMain (C:\godot_source\platform\windows\godot_windows.cpp:234)
[42] __scrt_common_main_seh (D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
[43] <couldn't map PC to fn name>
-- END OF BACKTRACE --

Doesn't seem to crash on Linux, possibly Windows specific (or maybe also on macOS with case insensitive filesystem).

authors: Flynsarmy KoBeWi akien-mga


text:
[DX12] Crash on startup due to missing transfer worker command buffer

Tested versions

Reproduced in Godot v4.4.dev (92e51fca7)
Reproduced in Godot v4.4.dev (98deb2a00)
Cannot reproduce in Godot v4.4.dev (3b41f7310)

System information
Windows 10.0.26100 - Multi-window, 1 monitor - Vulkan (Forward+) - integrated AMD Radeon(TM) 780M (Advanced Micro Devices, Inc.; 31.0.24018.2001) - AMD Ryzen 7 7840U w/ Radeon  780M Graphics (16 threads)
Issue description
Attempting to start the editor or run any project using the D3D driver leads to a crash when Godot attempts to create the default white cubemap texture in texture_storage.cpp:255:
default_rd_textures[DEFAULT_RD_TEXTURE_CUBEMAP_ARRAY_WHITE] = RD::get_singleton()->texture_create(tformat, RD::TextureView(), vpv);

This appears to be due to the command buffer on the transfer worker being invalid during the texture creation, which leads to a null pointer being de-referenced in rendering_device.cpp:5110:

I believe this is a regression caused by #90400. I used git bisect to identify 98deb2a00 as the commit that caused this regression.
Full debug log (with DLL load messages stripped):
Godot Engine v4.4.dev.custom_build.92e51fca7 (2024-10-10 23:13:24 UTC) - https://godotengine.org
onecore\windows\directx\dxcore\dll\dxcore-win.cpp(927)\dxcore.dll!00007FFE6CABF8EA: (caller: 00007FFE6CAB29B1) Exception(1) tid(317e8) C0000034 Object Name not found.
Exception thrown at 0x00007FFE6FBB83EA in godot.windows.editor.dev.x86_64.exe: Microsoft C++ exception: wil::ResultException at memory location 0x0000008C19BF1660.
D3D Error 887e0003: (202728@233241203) at 00007FFE5CA76ED4 - Unable to load D3D12Core.dll.  Verify D3D12SDKPath is correct.
Microsoft.Direct3DUndocked\src\D3D\module.cpp(728)\D3D12.dll!00007FFE5CA76EF8: (caller: 00007FFE5CA7EBD5) LogHr(1) tid(317e8) 887E0003 The D3D12 SDK version configuration of the host exe is invalid.
    Msg:[Unable to load D3D12Core.dll.  Verify D3D12SDKPath is correct.]
D3D12 12_0 - Forward+ - Using Device #0: AMD - AMD Radeon(TM) 780M
WARNING: PSO caching is not implemented yet in the Direct3D 12 driver.
     at: RenderingDeviceDriverD3D12::pipeline_cache_create (drivers\d3d12\rendering_device_driver_d3d12.cpp:4876)
drivers\d3d12\rendering_device_driver_d3d12.cpp:4876 - PSO caching is not implemented yet in the Direct3D 12 driver.
ERROR: Close failed with error 0x80070057.
   at: (drivers\d3d12\rendering_device_driver_d3d12.cpp:2358)
Close failed with error 0x80070057.
Exception thrown at 0x00007FFE6FBB83EA in godot.windows.editor.dev.x86_64.exe: Microsoft C++ exception: _com_error at memory location 0x0000008C19BF24D0.
D3D12: Removing Device.
ERROR: Reset failed with error 0x80070057.
   at: (drivers\d3d12\rendering_device_driver_d3d12.cpp:2341)
Reset failed with error 0x80070057.
Exception thrown at 0x00007FFE6FBB83EA in godot.windows.editor.dev.x86_64.exe: Microsoft C++ exception: _com_error at memory location 0x0000008C19BF2AB8.
ERROR: Map failed with error 0x887a0005.
   at: (drivers\d3d12\rendering_device_driver_d3d12.cpp:899)
Map failed with error 0x887a0005.
ERROR: Parameter "write_ptr" is null.
   at: RenderingDevice::_texture_initialize (servers\rendering\rendering_device.cpp:1260)
servers\rendering\rendering_device.cpp:1260 - Parameter "write_ptr" is null.
Exception thrown at 0x00007FFE6FBB83EA in godot.windows.editor.dev.x86_64.exe: Microsoft C++ exception: _com_error at memory location 0x0000008C19BF2668.
Exception thrown at 0x00007FFE6FBB83EA in godot.windows.editor.dev.x86_64.exe: Microsoft C++ exception: _com_error at memory location 0x0000008C19BF28B0.
ERROR: Condition "!(((HRESULT)(res)) >= 0)" is true. Returning: FenceID()
   at: RenderingDeviceDriverD3D12::fence_create (drivers\d3d12\rendering_device_driver_d3d12.cpp:2148)
drivers\d3d12\rendering_device_driver_d3d12.cpp:2148 - Condition "!(((HRESULT)(res)) >= 0)" is true. Returning: FenceID()
Exception thrown at 0x00007FFE6FBB83EA in godot.windows.editor.dev.x86_64.exe: Microsoft C++ exception: _com_error at memory location 0x0000008C19BF2678.
Exception thrown at 0x00007FFE6FBB83EA in godot.windows.editor.dev.x86_64.exe: Microsoft C++ exception: _com_error at memory location 0x0000008C19BF28C0.
ERROR: Condition "!(((HRESULT)(res)) >= 0)" is true. Returning: SemaphoreID()
   at: RenderingDeviceDriverD3D12::semaphore_create (drivers\d3d12\rendering_device_driver_d3d12.cpp:2182)
drivers\d3d12\rendering_device_driver_d3d12.cpp:2182 - Condition "!(((HRESULT)(res)) >= 0)" is true. Returning: SemaphoreID()
Exception thrown at 0x00007FFE6FBB83EA in godot.windows.editor.dev.x86_64.exe: Microsoft C++ exception: _com_error at memory location 0x0000008C19BF2598.
Exception thrown at 0x00007FFE6FBB83EA in godot.windows.editor.dev.x86_64.exe: Microsoft C++ exception: _com_error at memory location 0x0000008C19BF27D0.
Exception thrown at 0x00007FFE6FBB83EA in godot.windows.editor.dev.x86_64.exe: Microsoft C++ exception: _com_error at memory location 0x0000008C19BF2840.
ERROR: CreateCommandAllocator failed with error 0x887a0005.
   at: (drivers\d3d12\rendering_device_driver_d3d12.cpp:2308)
CreateCommandAllocator failed with error 0x887a0005.
Exception thrown at 0x00007FFE6FBB83EA in godot.windows.editor.dev.x86_64.exe: Microsoft C++ exception: _com_error at memory location 0x0000008C19BF18C8.
Exception thrown at 0x00007FFE6FBB83EA in godot.windows.editor.dev.x86_64.exe: Microsoft C++ exception: _com_error at memory location 0x0000008C19BF1B30.
Exception thrown at 0x00007FFE6FBB83EA in godot.windows.editor.dev.x86_64.exe: Microsoft C++ exception: _com_error at memory location 0x0000008C19BF1BA0.
ERROR: Can't create buffer of size: 16384, error 0x887a0005.
   at: (drivers\d3d12\rendering_device_driver_d3d12.cpp:863)
Can't create buffer of size: 16384, error 0x887a0005.
Exception thrown at 0x00007FF6497F732A in godot.windows.editor.dev.x86_64.exe: 0xC0000005: Access violation reading location 0x0000000000000000.

Steps to reproduce

Compile the engine with D3D support.
Run the editor and try to load or create a project.  Alternatively, try to run a project directly from the command line.

Minimal reproduction project (MRP)
N/A

Cc @DarioSamo

Commenting to assign and investigate this further during the week.

I've investigated this and the reason seems to be that the barrier transitions are not allowed in D3D12 from Copy queues to transition into a shader read only layout when enhanced barriers are enabled, leading to the device crashing and failing on any future calls.
In theory this would be solvable by either of two approaches:

D3D12 is forced to use direct queues for transfer workers instead (not ideal).
Any pending barrier transitions are pushed to the main queue instead when the time is right.

I'll see what I can do about it but this will require some refactoring to get it right.

I tested with #98271 and I'm no longer seeing the crash or any of the errors I was seeing before.
I believe this PR fixes the issue.
Thanks!

I can't reproduce this on 4.4.dev https://github.com/godotengine/godot/commit/4631a617e5ab4ec5cc51dbc43609b269a43059d9. Nonetheless, https://github.com/godotengine/godot/pull/98271 still makes sense to merge.

PC specifications

CPU: Intel Core i9-13900K
GPU: NVIDIA GeForce RTX 4090
RAM: 64 GB (2×32 GB DDR5-5800 C30)
SSD: Solidigm P44 Pro 2 TB
OS: Windows 11 23H2

I can't reproduce this on 4.4.dev 4631a61 when following the steps described here (even though D3D12 is definitely being used). Nonetheless, #98271 still makes sense to merge.

You need enhanced barrier support in your driver for the error to show up. I would check if your capabilities report it as true during initialization.

authors: Calinou DarioSamo DarkKilauea clayjohn


text:
FileAccess store_line() overwriting files instead of appending to files without seek_end()

Tested versions
Reproducible since 4.3-beta3 up until now 4.4-dev3
System information
Windows 10 Pro - Godot v4.3.stable.steam [77dcf97d8]
Issue description
Per the docs, FileAccess' store_line() method is defined as:

void store_line(line: String)
Appends line to the file followed by a line return character (\n), encoding the text as UTF-8.

The use of Appends here would imply that it would just add to a file ending with a trailing \n. However, the use of WRITE, WRITE_READ, and READ_WRITE cause the file to be overwritten completely. The only way to truly append a file with store_line() is to use the seek_end() method first.
The Ask: Either (1) Update the docs to more accurately explain what store_line() does, or (2) Revisit the engine code for store_line() and confirm whether it should actually append to a file.
Docs Link: https://docs.godotengine.org/en/stable/classes/class_fileaccess.html#class-fileaccess-method-store-line
Steps to reproduce
extends Node

func _ready() -> void:
	var file_no_seek: FileAccess
	var file_with_seek: FileAccess

	if !FileAccess.file_exists("user://no-seek.txt"):
		file_no_seek = FileAccess.open("user://no-seek.txt", FileAccess.WRITE_READ)
		print("no-seek.txt created at: " + OS.get_user_data_dir() + "/no-seek.txt")
	else:
		file_no_seek = FileAccess.open("user://no-seek.txt", FileAccess.READ_WRITE)
		print("no-seek.txt opened from: " + OS.get_user_data_dir() + "/no-seek.txt")

	file_no_seek.store_line(Time.get_datetime_string_from_system() + " - Attempt to increment no-seek.txt")
	print("no-seek.txt file contents:\n" + file_no_seek.get_as_text())
	file_no_seek.close()
	print("Successfully closed no-seek.txt")

	if !FileAccess.file_exists("user://with-seek.txt"):
		file_with_seek = FileAccess.open("user://with-seek.txt", FileAccess.WRITE_READ)
		print("with-seek.txt created at: " + OS.get_user_data_dir() + "/with-seek.txt")
	else:
		file_with_seek = FileAccess.open("user://with-seek.txt", FileAccess.READ_WRITE)
		print("with-seek.txt opened from: " + OS.get_user_data_dir() + "/with-seek.txt")

	file_with_seek.seek_end()
	file_with_seek.store_line(Time.get_datetime_string_from_system() + " - Attempt to increment with-seek.txt")
	print("with-seek.txt file contents:\n" + file_with_seek.get_as_text())
	file_with_seek.close()
	print("Successfully closed with-seek.txt")

	return

Note the following print() outputs:

no-seek.txt opened from: C:/Users/$ME/AppData/Roaming/Godot/app_userdata/StoreLineRepro/no-seek.txt
no-seek.txt file contents:
2024-10-16T10:15:55 - Attempt to increment no-seek.txt
Successfully closed no-seek.txt
with-seek.txt opened from: C:/Users/$ME/AppData/Roaming/Godot/app_userdata/StoreLineRepro/with-seek.txt
with-seek.txt file contents:
2024-10-16T10:15:37 - Attempt to increment with-seek.txt
2024-10-16T10:15:46 - Attempt to increment with-seek.txt
2024-10-16T10:15:55 - Attempt to increment with-seek.txt
Successfully closed with-seek.txt

This shows store_line() does end with a trailing \n, but even in READ_WRITE it overwrites the file without the use of seek_end() first.
Minimal reproduction project (MRP)
MRP made in v4.3.stable.steam:
StoreLineRepro.zip

@aaron-bigadventurecrew see this PR #98238

@syntaxerror247 That PR encapsulates the need well, this issue can be closed once merged. My intention of raising the issue was to give a simple MRP for the team's review anyways since explaining it can be a bit much. Thank you!

Still pending the live docs page to be updated reflecting the PR Merge:
https://docs.godotengine.org/en/stable/classes/class_fileaccess.html#class-fileaccess-method-store-line
Clear browser cache (Ctrl+Shift+R):
Request URL:
https://docs.godotengine.org/en/stable/classes/class_fileaccess.html
Request Method:
GET
Status Code:
200 OK
Referrer Policy:
strict-origin-when-cross-origin

access-control-allow-methods:
HEAD, OPTIONS, GET
access-control-allow-origin:
*
age:
6402
cache-control:
max-age=1200
cdn-cache-control:
public
cf-cache-status:
DYNAMIC
content-encoding:
zstd
content-type:
text/html; charset=utf-8
date:
Wed, 16 Oct 2024 20:08:51 GMT
last-modified:
Fri, 04 Oct 2024 03:31:29 GMT

Follow-up normal refresh:
Request URL:
https://docs.godotengine.org/en/stable/classes/class_fileaccess.html
Request Method:
GET
Status Code:
304 Not Modified
Referrer Policy:
strict-origin-when-cross-origin

access-control-allow-methods:
HEAD, OPTIONS, GET
access-control-allow-origin:
*
age:
6615
cache-control:
max-age=1200
cdn-cache-control:
public
cf-cache-status:
DYNAMIC
date:
Wed, 16 Oct 2024 20:12:24 GMT
etag:
W/"fefc62705638391dc44bb2e0341f4c50"
last-modified:
Fri, 04 Oct 2024 03:31:29 GMT

Still pending the live docs page to be updated reflecting the PR Merge:
https://docs.godotengine.org/en/stable/classes/class_fileaccess.html#class-fileaccess-method-store-line

This is a link to the stable docs, it will only be updated when PR is cherry-picked for 4.3, new changes applied to the latest docs. But sync class reference GitHub action is set to only run every Saturday, so latest docs won't be updated until then.

@bruvzg Oh ok sounds good then! You can mark this as resolved whenever you'd like, the changes to the wording in the PR make sense to me and explain why my reported behavior happened.

is this fixed on godot 4.4? Im on 4.2 and having this exact issue

@GitExcel It was a documentation error, which has now been corrected. The behavior of store_line() overwriting the file is expected. To append data instead, you can use seek_end() first.

authors: GitExcel aaron-bigadventurecrew bruvzg syntaxerror247


text:
Fix UWP build after #14622.

Fixes #19009

Thanks!

Compiles now, stuck on the angle binaries I'm using needing VCRUNTIME140 instead of VCRUNTIME141 but I'll get those installed. Stupid microsoft VC runtimes...

source: gharchive/pull-request

authors: BastiaanOlij akien-mga bruvzg


text:
Misc Cppcheck fixes

Partially fixes #22702.

Thanks for the fixes, I've rebased them and merged as 10718b096.

authors: akien-mga swenner


text:
[3.2] Fix port previews for uniforms in visual shaders

Backport #45659

Hmm.. or maybe this is not a correct way to fix it, and this should be fixed at EditorHistory level

Thanks!

authors: Chaosus akien-mga


text:
GDScript: False positive "Identifier not found" error on signals fixed

Fix: #45900
extends Node2D

func _on_hide():
	print('_on_hide() called.')

func _ready():
	hidden.connect(_on_hide)
	hide()

## prints "_on_hide() called."

To review the code changes without the whitespace change: https://github.com/godotengine/godot/pull/46379/files?w=1

Thanks!

authors: ThakeeNathees akien-mga


text:
Add a project setting to adjust VoxelGI dynamic oversampling

Follow-up to https://github.com/godotengine/godot/pull/55418.
The default is now to have oversampling disabled, as it brings a very significant performance boost (going from 42 FPS to 137 FPS in a complex test scene with a dozen dynamic objects).
It's recommended to enable oversampling only when it brings a noticeable benefit (such as with small, slow-moving objects that have emissive materials).
Note: The setting currently can't be changed at run-time, as I couldn't figure out how to force a VoxelGI update when the setting changes.
This closes https://github.com/godotengine/godot/issues/55359.
Testing project: test_voxelgi_performance_complex.zip
Performance
With the test scene linked above, a GTX 1080 and 2560×1440 resolution:

Mode
Performance

Oversampling disabled
130 FPS (7.69 mspf)

2× oversampling
125 FPS (8.00 mspf)

4× oversampling
111 FPS (9.01 mspf)

8× oversampling
82 FPS (12.20 mspf)

16× oversampling
40 FPS (25.00 mspf)

Note that this was measured without https://github.com/godotengine/godot/pull/55418 included. When https://github.com/godotengine/godot/pull/55418 is included, overall performance is slightly higher on all oversampling levels (including disabled). The benefit of https://github.com/godotengine/godot/pull/55418 is greater at higher oversampling levels, still.
Preview
Oversampling disabled (new default, fast)
https://user-images.githubusercontent.com/180032/143783108-397079f6-f5b1-4b73-a2e1-5b5b555cdf12.mp4
2× oversampling (average)
https://user-images.githubusercontent.com/180032/143783099-7fa066e9-7d65-465a-a74b-8df8c7b8a7f5.mp4
4× oversampling (slow)
https://user-images.githubusercontent.com/180032/143783102-d43d3542-af5e-4abb-847c-1094a5c48429.mp4
8× oversampling (slower)
https://user-images.githubusercontent.com/180032/143783105-86d6e09d-74c8-495e-8ad8-7a89ab69e216.mp4
16× oversampling (current default, slowest)
https://user-images.githubusercontent.com/180032/143783107-f30dc9ee-de9e-4e2e-b1f3-78670d9df325.mp4

Give me some time, I want to rework this.

Rebased and tested again, it works as expected.
Benchmark on a AMD Radeon RX 6900 XT (Mesa RADV):
1152×648
Disabled | 503 FPS (1.98 mspf)
2× | 493 FPS (2.02 mspf)
4× | 428 FPS (2.33 mspf)
8× | 493 FPS (2.02 mspf)
16× | 487 FPS (2.05 mspf)
3840×2160
Mode | Performance
Disabled | 285 FPS (3.50 mspf)
2× | 266 FPS (3.75 mspf)
4× | 229 FPS (4.36 mspf)
8× | 275 FPS (3.63 mspf)
16× | 266 FPS (3.75 mspf)
It's strange how 4× is actually the slowest level by a noticeable margin, rather than 16×. Both 8× and 16× look better than 4× but are faster. I could reproduce this across several runs (and the GPU is forced into a high power state with gamemode), so it's not a one-time fluke.

Give me some time, I want to rework this.

Considering the VoxelGI rework will have to be done after 4.0, can we merge this as a stopgap? It makes the difference between dynamic objects being unusable and being usable on mid-range/high-end dedicated GPUs.

Considering the VoxelGI rework will have to be done after 4.0, can we merge this as a stopgap? It can make the difference between dynamic objects being unusable and being usable on mid-range/high-end dedicated GPUs.

I'm not sure this is the right approach right now. Especially seeing as the performance difference has all but disappeared in your recent tests

Especially seeing as the performance difference has all but disappeared in your recent tests

I no longer have the GTX 1080 in a machine, but I've noticed quite a few performance differentials that don't make sense. A RX 6900 XT is on average 2.5 times faster in rasterization, but here, it was more than 5 times as fast on average, despite running at a higher output resolution in my tests (3840×2160 on the 6900 XT, 2560×1440 on the GTX 1080).
It's possible that this PR still positively impacts performance on NVIDIA, as I remember Godot 4 having many optimizations that favor AMD GPUs.

@yosoyfreeman Once CI passes, could you test this pull request locally on your system to see how much it improves performance?

Never tried pull request but I'll do my best to learn. If I'm too slow for this one at least it will serve me to provide better information in future issues.  But yes, i'm going to try.

PD: I had to use the mono editor version cause there is not a build for the normal Linux one. Is this common practice? to know it for the next time.

Yes, our CI build matrix has to be limited to keep resource usage to a reasonable level.

authors: Calinou clayjohn reduz yosoyfreeman


text:
[3.x] Support WebM seeking operation

Support webm video seeking operation with minimal modification. Currently, it only support 3.x version since master 4.0 version has abandoned webm format support.
Modified files:
1.modules/webm/video_stream_webm.cpp
2.thirdparty/libsimplewebm/WebMDemuxer.cpp
3.thirdparty/libsimplewebm/WebMDemuxer.hpp

https://user-images.githubusercontent.com/99071212/152667074-e226a8f6-b3d7-4ef0-b5af-31bec11eeb61.mp4

see https://github.com/godotengine/godot/issues/14430

see #14430

Thanks for your feedback, since I'm not an expert in video decoding, but I'll try my best to fix this issue.

see #14430

@jamie-pate i have fix the issue, and please verify it on 1ede4ca4bdc5ae39081bb199541594054fbda161. Thanks!

@John-Gdi nice work！ Do you know how to fix VideoStreamWebm playing slowly in Html5? I really want to know where the problem is.

@John-Gdi nice work！ Do you know how to fix VideoStreamWebm playing slowly in Html5? I really want to know where the problem is.

Video decoding will always perform poorly in HTML5 for two reasons:

yasm assembly cannot be used.
Decoding is performed on the CPU, via a pure C WebAssembly layer, which is slow.

@John-Gdi nice work！ Do you know how to fix VideoStreamWebm playing slowly in Html5? I really want to know where the problem is.

You would likely need a whole new way to play video in the html version.. using the built in video element to create a texture for webgl (like this https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Animating_textures_in_WebGL ). godot's OS.native_video_play https://docs.godotengine.org/en/stable/classes/class_os.html#class-os-method-native-video-play call would be another way, but docs say they are only currently implemented for ios)

Oh, god. I can't handle this work now.(crying...... :< )

make the attached vp8 and vp9 webm file plays properly <- this commit does not appear to create a performance regression, and I can confirm that the video which is broken in the reproduction plays correctly with up to 4x video streams being decoded concurrently.
perf.log
When playing a file that was encoded with vp9 and did not fail to playback in the previous version of godot the frame rate was roughly the same for both commits, and only slightly slower than the godot-videodecoder plugin...
GODOT=./libvp9-thread-godot.x11.opt.tools.64
Godot Engine v3.3.5.rc.custom_build.63ac434b3 - https://godotengine.org
Playing char-waypoints-2022-01-27_20.08.38.webm 4x with builtin decoder

videos:0 fps:7673 ts:10091
videos:1 fps:6419 ts:15090
videos:2 fps:4412 ts:20090
videos:3 fps:4037 ts:25090
videos:4 fps:3663 ts:30090
videos:4 fps:3837 ts:35090
videos:4 fps:3711 ts:40090
videos:3 fps:4109 ts:45090
videos:2 fps:4364 ts:50090
videos:1 fps:4635 ts:55090
videos:0 fps:4994 ts:60090

GODOT=./libvp9-nothread-godot.x11.opt.tools.64
Godot Engine v3.5.beta.custom_build.1ede4ca4b - https://godotengine.org
Playing char-waypoints-2022-01-27_20.08.38.webm 4x with builtin decoder
videos:0 fps:1 ts:1
videos:0 fps:9063 ts:5111
videos:0 fps:8985 ts:10112
videos:1 fps:4349 ts:15112
videos:2 fps:6185 ts:20112
videos:3 fps:3474 ts:25112
videos:4 fps:2253 ts:30112
videos:4 fps:2986 ts:35112
videos:4 fps:4589 ts:40112
videos:3 fps:3449 ts:45112
videos:2 fps:3934 ts:50112
videos:1 fps:4388 ts:55112
videos:0 fps:4907 ts:60112

make the attached vp8 and vp9 webm file plays properly <- this commit does not appear to create a significant performance regression, and I can confirm that the video which is broken in the reproduction plays correctly with up to 4x video streams being decoded concurrently. (probably need a better way to measure performance though than decoding 4 concurrent video streams)
perf.log i7-8750H perf-u620-i7-8650U.log
When playing a file that was encoded with vp9 and did not fail to playback in the previous version of godot the frame rate was roughly the same for both commits, and only slightly slower than the godot-videodecoder plugin...
i7-8750H
GODOT=./libvp9-thread-godot.x11.opt.tools.64
Godot Engine v3.3.5.rc.custom_build.63ac434b3 - https://godotengine.org
Playing char-waypoints-2022-01-27_20.08.38.webm 4x with builtin decoder

videos:0 fps:7673 ts:10091
videos:1 fps:6419 ts:15090
videos:2 fps:4412 ts:20090
videos:3 fps:4037 ts:25090
videos:4 fps:3663 ts:30090
videos:4 fps:3837 ts:35090
videos:4 fps:3711 ts:40090
videos:3 fps:4109 ts:45090
videos:2 fps:4364 ts:50090
videos:1 fps:4635 ts:55090
videos:0 fps:4994 ts:60090

GODOT=./libvp9-nothread-godot.x11.opt.tools.64
Godot Engine v3.5.beta.custom_build.1ede4ca4b - https://godotengine.org
Playing char-waypoints-2022-01-27_20.08.38.webm 4x with builtin decoder
videos:0 fps:1 ts:1
videos:0 fps:9063 ts:5111
videos:0 fps:8985 ts:10112
videos:1 fps:4349 ts:15112
videos:2 fps:6185 ts:20112
videos:3 fps:3474 ts:25112
videos:4 fps:2253 ts:30112
videos:4 fps:2986 ts:35112
videos:4 fps:4589 ts:40112
videos:3 fps:3449 ts:45112
videos:2 fps:3934 ts:50112
videos:1 fps:4388 ts:55112
videos:0 fps:4907 ts:60112

i7-8650U

GODOT=./libvp9-nothread-godot.x11.opt.tools.64
Godot Engine v3.5.beta.custom_build.1ede4ca4b - https://godotengine.org
Playing char-waypoints-2022-01-27_20.08.38.webm 4x with builtin decoder
videos:0 fps:2945 ts:6353
videos:0 fps:2898 ts:11353
videos:1 fps:950 ts:16354
videos:2 fps:492 ts:21355
videos:3 fps:333 ts:26354
videos:4 fps:232 ts:31360
videos:4 fps:238 ts:36357
videos:4 fps:234 ts:41359
videos:3 fps:274 ts:46359
videos:2 fps:304 ts:51355
videos:1 fps:336 ts:56358
videos:0 fps:366 ts:61359

GODOT=./libvp9-thread-godot.x11.opt.tools.64
Godot Engine v3.5.beta.custom_build.0c58454da - https://godotengine.org
videos:0 fps:2834 ts:6338
videos:0 fps:2554 ts:11339
videos:1 fps:954 ts:16340
videos:2 fps:515 ts:21339
videos:3 fps:366 ts:26342
videos:4 fps:279 ts:31342
videos:4 fps:278 ts:36341
videos:4 fps:281 ts:41340
videos:3 fps:299 ts:46342
videos:2 fps:320 ts:51342
videos:1 fps:341 ts:56345
videos:0 fps:363 ts:61344

Complete name                            : char-waypoints-2022-01-27_20.08.38.webm
Format                                   : VP9
Width                                    : 1 434 pixels
Height                                   : 660 pixels

Complete name                            : vp8-encoded.webm
Format                                   : VP8
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels

Complete name                            : vp9-encoded.webm
Format                                   : VP9
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels

Thanks for your test, and hope this pr can satisfy some pepole's needs

@John-Gdi nice work！ Do you know how to fix VideoStreamWebm playing slowly in Html5? I really want to know where the problem is.

Video decoding will always perform poorly in HTML5 for two reasons:

yasm assembly optimizations cannot be used.
Decoding is performed on the CPU, via a pure C WebAssembly layer, which is slow.

There isn't a good way to work around this, as WebAssembly cannot make use of the browser's native video decoding functionality (which would allow for hardware-accelerated decoding). Theora might perform better as it's less demanding on the CPU, but I wouldn't expect it to be fantastic there either.
@Calinou
Can the technology in the link below make it possible to play webm videos smoothly?
https://github.com/GoogleChromeLabs/webm-wasm

Can the technology in the link below make it possible to play webm videos smoothly?
https://github.com/GoogleChromeLabs/webm-wasm

"This is a proof-of-concept and not a production-grade library."
It looks like it's for encoding video files from raw frames... Also probably not real time

@jamie-pate @Calinou
Mainly I want to be able to play webm video smoothly in HTML5, but can't find any technology to replace it, although Ogg Theora video does what I want, it's too low definition. I'm wondering if it's possible to pre-decode webm-formatted videos while packing. . .

Ogg Theora shouldn't be low definition, it depends on how you encoded the video, like any encoder.

Is it because I set it wrong? The resolution of the video is not as good as the webm format.
@akien-mga

Your bitrate is set to 6 Mb/s, which is quite low by today's standards, especially for Ogg Theora which is less efficient than H.264 or VP9.

Your video encoding bitrate is set to 6 Mb/s, which is quite low by today's standards, especially for Ogg Theora which is less efficient than H.264 or VP9. For comparison, 1080p60 H.264 video on YouTube is around 10 Mb/s, but even that is considered low quality nowadays (and that's for a more efficient format).
To make things worse, you're using the Realtime encoding speed preset, which favors speed over quality (for a given bitrate). Use a encoding slower preset to get better quality with the same bitrate – it doesn't affect decoding speed.

Great, after modifying the settings, the effect is much better now.

The current lack of seek() for the VideoPlayer node is what makes this node pretty much useless for me. From my tests there is no way to work around this issue.
Also all previous proposals and issues have been closed.
I'm very happy to see someone is working on this, may I ask what is left for it to be merged? Are there any plans for ogv seek support as well?

I'm very happy to see someone is working on this, may I ask what is left for it to be merged? Are there any plans for ogv seek support as well?

Please test the PR locally and report if it works :slightly_smiling_face:

Are there any plans for ogv seek support as well?

This was being worked on in https://github.com/godotengine/godot/pull/32539, but it needs to be salvaged.

Please test the PR locally and report if it works

I would love to, but the Windows artifacts are apparently already expired. And I don't feel competent enough to compile and build Godot with these changes.

I tested it on my end (GNU/Linux), and it doesn't appear to work. The video just goes back to the beginning.
I'm using this file for testing: https://filesamples.com/samples/video/webm/sample_960x400_ocean_with_audio.webm

@John-Gdi Could you look into testing your PR with the file linked by YeldhamDev above?

authors: Atem1995 Calinou John-Gdi YeldhamDev akien-mga golddotasksquestions jamie-pate


text:
Rename WinRT platform to UWP

Using the legacy name usually causes confusion, Universal Windows Platform is now the official name for it.
Note: rename the winrt tag here in GitHub when this is merged.

I like the legacy names so I vote no (but it's just a vote, I'm fine if
everyone else prefers the new name)
On 2 November 2016 at 19:25, George Marques notifications@github.com
wrote:

Using the legacy name usually causes confusion, Universal Windows Platform
is now the official name for it.
Note: rename the winrt tag here in GitHub when this is merged.
You can view, comment on, or merge this pull request online at:
https://github.com/godotengine/godot/pull/7019
Commit Summary

Rename WinRT files to UWP
Rename WINRT_ENABLED to UWP_ENABLED
Rename remaining WinRT references to UWP

File Changes

M doc/base/classes.xml
https://github.com/godotengine/godot/pull/7019/files#diff-0 (2)
M drivers/unix/ip_unix.cpp
https://github.com/godotengine/godot/pull/7019/files#diff-1 (4)
M drivers/unix/socket_helpers.h
https://github.com/godotengine/godot/pull/7019/files#diff-2 (2)
M drivers/windows/dir_access_windows.cpp
https://github.com/godotengine/godot/pull/7019/files#diff-3 (2)
M drivers/windows/file_access_windows.cpp
https://github.com/godotengine/godot/pull/7019/files#diff-4 (4)
M drivers/windows/mutex_windows.cpp
https://github.com/godotengine/godot/pull/7019/files#diff-5 (2)
M drivers/windows/semaphore_windows.cpp
https://github.com/godotengine/godot/pull/7019/files#diff-6 (2)
M drivers/windows/shell_windows.cpp
https://github.com/godotengine/godot/pull/7019/files#diff-7 (2)
M drivers/windows/thread_windows.cpp
https://github.com/godotengine/godot/pull/7019/files#diff-8 (2)
M main/input_default.cpp
https://github.com/godotengine/godot/pull/7019/files#diff-9 (4)
M modules/freetype/SCsub
https://github.com/godotengine/godot/pull/7019/files#diff-10 (6)
R modules/freetype/uwpdef.h
https://github.com/godotengine/godot/pull/7019/files#diff-11 (2)
M modules/openssl/SCsub
https://github.com/godotengine/godot/pull/7019/files#diff-12 (8)
M modules/webm/libvpx/SCsub
https://github.com/godotengine/godot/pull/7019/files#diff-13 (8)
R platform/uwp/SCsub
https://github.com/godotengine/godot/pull/7019/files#diff-14 (6)
R platform/uwp/app.cpp
https://github.com/godotengine/godot/pull/7019/files#diff-15 (16)
R platform/uwp/app.h
https://github.com/godotengine/godot/pull/7019/files#diff-16 (6)
R platform/uwp/detect.py
https://github.com/godotengine/godot/pull/7019/files#diff-17 (8)
R platform/uwp/export/export.cpp
https://github.com/godotengine/godot/pull/7019/files#diff-18 (64)
R platform/uwp/export/export.h
https://github.com/godotengine/godot/pull/7019/files#diff-19 (2)
R platform/uwp/gl_context_egl.cpp
https://github.com/godotengine/godot/pull/7019/files#diff-20 (0)
R platform/uwp/gl_context_egl.h
https://github.com/godotengine/godot/pull/7019/files#diff-21 (0)
R platform/uwp/joystick_uwp.cpp
https://github.com/godotengine/godot/pull/7019/files#diff-22 (26)
R platform/uwp/joystick_uwp.h
https://github.com/godotengine/godot/pull/7019/files#diff-23 (12)
R platform/uwp/logo.png
https://github.com/godotengine/godot/pull/7019/files#diff-24 (0)
R platform/uwp/os_uwp.cpp
https://github.com/godotengine/godot/pull/7019/files#diff-25 (160)
R platform/uwp/os_uwp.h
https://github.com/godotengine/godot/pull/7019/files#diff-26 (18)
R platform/uwp/platform_config.h
https://github.com/godotengine/godot/pull/7019/files#diff-27 (0)
R platform/uwp/thread_uwp.cpp
https://github.com/godotengine/godot/pull/7019/files#diff-28 (28)
R platform/uwp/thread_uwp.h
https://github.com/godotengine/godot/pull/7019/files#diff-29 (20)
M thirdparty/README.md
https://github.com/godotengine/godot/pull/7019/files#diff-30 (2)
M thirdparty/enet/win32.c
https://github.com/godotengine/godot/pull/7019/files#diff-31 (6)
M thirdparty/openssl/crypto/rand/rand_win.c
https://github.com/godotengine/godot/pull/7019/files#diff-32 (10)
M thirdparty/openssl/openssl/dtls1.h
https://github.com/godotengine/godot/pull/7019/files#diff-33 (2)
R thirdparty/openssl/uwp.cpp
https://github.com/godotengine/godot/pull/7019/files#diff-34 (8)
R thirdparty/openssl/uwp_fix.patch
https://github.com/godotengine/godot/pull/7019/files#diff-35 (12)
M thirdparty/rtaudio/RtAudio.h
https://github.com/godotengine/godot/pull/7019/files#diff-36 (2)
M tools/dist/uwp_template/AppxManifest.xml
https://github.com/godotengine/godot/pull/7019/files#diff-37 (2)

Patch Links:

https://github.com/godotengine/godot/pull/7019.patch
https://github.com/godotengine/godot/pull/7019.diff

—
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/pull/7019, or mute the thread
https://github.com/notifications/unsubscribe-auth/AGVmPVpji4uOKBh9Pgz-cyXHMEeAd7XJks5q6Q3cgaJpZM4Kn0f6
.

Well, I've seen some people making the confusion, thinking "WinRT" is just the old capped Windows 8 for tablets. I know that "Windows Runtime" is still used under the hood by Microsoft, but in Godot's case we specifically make UWP apps.
I'm not married to this change either, if others prefer the legacy name we can keep it.

I vote for rename
On Nov 2, 2016 22:19, "George Marques" notifications@github.com wrote:

Well, I've seen some people making the confusion, thinking "WinRT" is just
the old capped Windows 8 for tablets. I know that "Windows Runtime" is
still used under the hood by Microsoft, but in Godot's case we specifically
make UWP apps.
I'm not married to this change either, if others prefer the legacy name we
can keep it.
—
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/pull/7019#issuecomment-258046015,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2zd4s8z3l28OvaQsxn5LAkQQewvAks5q6TangaJpZM4Kn0f6
.

I would say, rename, so we can distinguish platforms better (win and winrt are pretty close as names).

I'd be for renaming too, though I don't have a strong opinion either way. Looks like other engines are trying to make the distinction between WinRT of Win8.1 and UWP clearer: http://xenko.com/blog/toward-a-better-dotnet/

authors: akien-mga bojidar-bg punto- reduz vnen


text:
Add options to show icon in Android TV and run app as Android launcher

For some reason AndroidManifest.xml files are not being used when building an app for Android. There are multiple reasons to add things to that file, but even though there are some places that tell the files are merged, it seems that it is always generated.
The reasons I had to modify this file are:

Add the intent category LEANBACK_LAUNCHER so it adds an icon to Android TV launchers.
Add the intent categories HOME and DEFAULT so a godot app can be used as a launcher itself (useful for kiosk experiences).

What I did in the end was to add these as export options, so the AndroidManifest generator adds these when the specific options are selected in the Export window.
Fixes part of https://github.com/godotengine/godot/issues/76963
Edit: doesn't actually fix that issue, as the AndroidManifest.xml problem persists. but it fixes the problem that the issue OP had.

Thanks! Based on the discussion in the issue, it should remain open until a more general problem is addressed.


text:
Add String.reverse method

Adds a simple method to return the copy of the string in reverse order. May be useful in some cases. Closes https://github.com/godotengine/godot-proposals/issues/3503

This implementation breaks some characters, eg "🇺🇦".reverse() == "🇦🇺"
Generally you would want to keep unicode grapheme clusters intact and just reverse their order, but in some locales a grapheme cluster is basically an entire word, so there it's probably not what you want either.
C# doesn't have this built-in because of exactly such problems, also its naive implementation would give different results.

TL/DR: this is a hard problem and I don't think this implementation does it justice.

I think the quirks of reversing should be documented as per the above mentioned

@RedworkDE This is a good point, but note that some graphemes are composed of multiple code points:
print("🇺🇦".length()) # 2

I think we can just document that the reverse() method considers code points under individual characters, not graphemes (sorry if I misused the terms).

Something like:
Note: This treats individual Unicode codepoints as individual characters, and may cause unexpected behaviour when reversing sequences including emoji, flags, etc.

I don't know a reverse() implementation that does NOT break flags/emoji and the like. Should be documented and that's all.

This implementation breaks some characters, eg "🇺🇦".reverse() == "🇦🇺"

None of the other String functions will handle composite emojis as a single character, so this is not an issue. Besides this, the result reversing string won't make any sense in many cases (any context dependent character combinations, combining diacritics etc.).

I agree that we shouldn't worry ourselves too much with how it handles complex unicode sequences and various composite languages. The resulting string won't be a valid word or sentence in practically any language. The application for this method lies somewhere else. Though the proposal doesn't elaborate why this is needed, only that it's needed.
If we seriously want to discuss if this is worth it or not, the proposal must provide some details for a use case of reversing a string, and doing so especially efficiently too to be considered a built-in (cc @me2beats). But we may also just YOLO this, as the naive implementation is pretty straightforward.

I used string reverse mainly for searching replacing and sorting
with and without Regex

Thanks!

authors: AThousandShips Chaosus RedworkDE YuriSizov Zireael07 akien-mga bruvzg dalexeev me2beats


text:
Fix invalid use of markdown syntax in classref

Also changed [b]true[/b] to [code]true[/code].

1. I checked it, I couldn't find any other matches for invalid use of Markdown. :+1:
2. Some possible incorrect [b] and [i]. I think [code] or class reference is more appropriate here.
https://github.com/godotengine/godot/blob/dcd187da9580b41688f4e5110acd767d4deab8de/doc/classes/%40GlobalScope.xml#L365-L366
https://github.com/godotengine/godot/blob/dcd187da9580b41688f4e5110acd767d4deab8de/doc/classes/%40GlobalScope.xml#L648
https://github.com/godotengine/godot/blob/dcd187da9580b41688f4e5110acd767d4deab8de/doc/classes/Area3D.xml#L9
https://github.com/godotengine/godot/blob/dcd187da9580b41688f4e5110acd767d4deab8de/doc/classes/AudioEffectDelay.xml#L41-L49
https://github.com/godotengine/godot/blob/dcd187da9580b41688f4e5110acd767d4deab8de/doc/classes/ConvexPolygonShape2D.xml#L9
3. This is more like material for another PR, but I noticed that some "strong" words ("not", "must") are sometimes in bold and sometimes in italics.

italic "not" - 54 matches
doc/classes/@GlobalScope.xml: 1
400: 35: 				[b]Note:[/b] This function is [i]not[/i] the same as [code]int(x)[/code], which rounds towards 0.
doc/classes/Array.xml: 2
378:160:  values. However, the reverse is not true. Returning identical hash values does [i]not[/i] imply the arrays are equal, because different arrays can have identical hash values due to hash
651:143: 	Compares the left operand [Array] against the [param right] [Array]. Returns [code]true[/code] if the sizes or contents of the arrays are [i]not[/i] equal, [code]false[/code] otherwise.
doc/classes/BaseMaterial3D.xml: 2
 62:143: ] and a [member detail_albedo] texture is specified, [member albedo_color] will [i]not[/i] modulate the detail texture. This can be used to color partial areas of a material by not speci
155: 43: 			[b]Note:[/b] [member detail_albedo] is [i]not[/i] modulated by [member albedo_color].
doc/classes/BoneAttachment3D.xml: 1
 28:246:  has a bone that has changed its pose. This function is where the BoneAttachment3D node updates its position so it is correctly bound when it is [i]not[/i] set to override the bone pose.
doc/classes/Callable.xml: 1
160:163:  values. However, the reverse is not true. Returning identical hash values does [i]not[/i] imply the callables are equal, because different callables can have identical hash values due t
doc/classes/Camera2D.xml: 1
181: 53: 			[b]Note:[/b] [member FontFile.oversampling] does [i]not[/i] take [Camera2D] zoom into account. This means that zooming in/out will cause bitmap fonts and rasterized (non-MSDF) dynamic
doc/classes/CanvasItem.xml: 2
293: 54: 				[b]Note:[/b] [member FontFile.oversampling] does [i]not[/i] take [param scale] into account. This means that scaling up/down will cause bitmap fonts and rasterized (non-MSDF) dynamic
590: 49: 			If [code]true[/code], this [CanvasItem] will [i]not[/i] inherit its transform from parent [CanvasItem]s. Its draw order will also be changed to make it draw on top of other [CanvasIte
doc/classes/Control.xml: 2
 16: 32: 		[b]Note:[/b] Theme items are [i]not[/i] [Object] properties. This means you can't access their values using [method Object.get] and [method Object.set]. Instead, use the [code]get_them
1022: 53: 			[b]Note:[/b] [member FontFile.oversampling] does [i]not[/i] take [Control] [member scale] into account. This means that scaling up/down will cause bitmap fonts and rasterized (non-MSD
doc/classes/Dictionary.xml: 1
264: 58: 				[b]Note:[/b] Dictionaries with equal hash values are [i]not[/i] guaranteed to be the same, because of hash collisions. On the contrary, dictionaries with different hash values are gu
doc/classes/EditorFileSystem.xml: 1
 17:147:  resource type of the file, given the full path. This returns a string such as [code]"Resource"[/code] or [code]"GDScript"[/code], [i]not[/i] a file extension such as [code]".gd"[/code].
doc/classes/EditorFileSystemDirectory.xml: 1
 71:147:  resource type of the file at index [param idx]. This returns a string such as [code]"Resource"[/code] or [code]"GDScript"[/code], [i]not[/i] a file extension such as [code]".gd"[/code].
doc/classes/EditorSettings.xml: 3
284:254: gle into account for the movement. The "Freelook Up" and "Freelook Down" keys will move in an "absolute" manner, [i]not[/i] taking the camera's pitch angle into account for the movement.
285:151: reelook Forward", "Freelook Backward", "Freelook Up" and "Freelook Down" keys will move in an "absolute" manner, [i]not[/i] taking the camera's pitch angle into account for the movement.
324:120: 			If [code]true[/code], invert the horizontal mouse axis when panning or orbiting in the 3D editor. This setting does [i]not[/i] apply to freelook mode.
doc/classes/Engine.xml: 2
 31: 54: 				[b]Note:[/b] [method get_architecture_name] does [i]not[/i] return the name of the host CPU architecture. For example, if running an x86_32 Godot binary on a x86_64 system, the retur
305:280: [code]false[/code] in a [code]@tool[/code] script, this will also impact the editor itself. Do [i]not[/i] report bugs before ensuring error messages are enabled (as they are by default).
doc/classes/GPUParticlesCollision3D.xml: 1
  8:158: 		Particle collision shapes in real-time and can be moved, rotated and scaled during gameplay. Unlike attractors, non-uniform scaling of collision shapes is [i]not[/i] supported.
doc/classes/GeometryInstance3D.xml: 1
 65:546: arency sorting. However, unlike using a transparent material, setting [member transparency] to a value greater than [code]0.0[/code] (exclusive) will [i]not[/i] disable shadow rendering.
doc/classes/Light3D.xml: 1
201: 37: 			[b]Note:[/b] Hiding a light does [i]not[/i] affect baking [LightmapGI]. Hiding a light will still affect baking [VoxelGI] and SDFGI (see [member Environment.sdfgi_enabled).
doc/classes/LightmapGI.xml: 1
125:174: [WorldEnvironment] node, this will act like [constant ENVIRONMENT_MODE_DISABLED]. The editor's preview sky and sun is [i]not[/i] taken into account by [LightmapGI] when baking lightmaps.
doc/classes/MovieWriter.xml: 2
 13:101: Writer is available for use in both the editor and exported projects, but it is [i]not[/i] designed for use by end users to record videos while playing. Players wishing to record gamepla
 56: 95: 				[b]Note:[/b] Pressing [kbd]Ctrl + C[/kbd] on the terminal running the editor/project does [i]not[/i] result in [method _write_end] being called.
doc/classes/Node.xml: 3
182: 71: 				[b]Note:[/b] For performance reasons, the order of node groups is [i]not[/i] guaranteed. The order of node groups should not be relied upon as it can vary across project runs.
301: 71: 				[b]Note:[/b] For performance reasons, the order of node groups is [i]not[/i] guaranteed. The order of node groups should not be relied upon as it can vary across project runs.
995:108: when the node's name or one of its parents' name is changed. This notification is [i]not[/i] received when the node is removed from the scene tree to be added to another parent later on.
doc/classes/OS.xml: 2
623:259: y process executed with [method execute] after running [method set_environment]. The environment variable will [i]not[/i] persist to processes run after the Godot process was terminated.
680:287: d with [method execute] after running [method unset_environment]. The removal of the environment variable will [i]not[/i] persist to processes run after the Godot process was terminated.
doc/classes/Object.xml: 1
 23:200: hout being set to [code]null[/code]. To check if an object has been deleted, do [i]not[/i] compare it against [code]null[/code]. Instead, use [method @GlobalScope.is_instance_valid]. It'
doc/classes/PolygonOccluder3D.xml: 1
 15: 21: 			The polygon must [i]not[/i] have intersecting lines. Otherwise, triangulation will fail (with an error message printed).
doc/classes/ProjectSettings.xml: 4
218:169: nt to display to the user that the editor must be restarted for changes to take effect. Enabling [method set_restart_if_changed] does [i]not[/i] delay the setting being set when changed.
2210:127: essing filter to make banding significantly less visible in 3D. 2D rendering is [i]not[/i] affected by debanding unless the [member Environment.background_mode] is [constant Environment.
2640: 44: 			[b]Note:[/b] Changing this setting does [i]not[/i] impact textures that were already imported before. To make this setting apply to textures that were already imported, exit the edito
2645: 44: 			[b]Note:[/b] Changing this setting does [i]not[/i] impact textures that were already imported before. To make this setting apply to textures that were already imported, exit the edito
doc/classes/RDPipelineMultisampleState.xml: 1
 22:439:  [code]1.0[/code], fragment invocation must only read from the coverage index sample. Tile image access must not be used if [member enable_sample_shading] is [i]not[/i] [code]1.0[/code].
doc/classes/RenderingServer.xml: 3
1390:126:  on the CPU in milliseconds. This value is shared across all viewports and does [i]not[/i] require [method viewport_set_measure_render_time] to be enabled on a viewport to be queried. Se
1688:458: parency sorting. However, unlike using a transparent material, setting [param transparency] to a value greater than [code]0.0[/code] (exclusive) will [i]not[/i] disable shadow rendering.
3698:278: ering/2d/sdf/scale]. This is used when sampling the signed distance field in [CanvasItem] shaders as well as [GPUParticles2D] collision. This is [i]not[/i] used by SDFGI in 3D rendering.
doc/classes/ResourceImporterScene.xml: 1
  9: 43: 		[b]Note:[/b] [ResourceImporterScene] is [i]not[/i] used for [PackedScene]s, such as [code].tscn[/code] and [code].scn[/code] files.
doc/classes/ResourceImporterShaderFile.xml: 1
  7:137: 		This imports native GLSL shaders as [RDShaderFile] resources, for use with low-level [RenderingDevice] operations. This importer does [i]not[/i] handle [code].gdshader[/code] files.
doc/classes/String.xml: 2
321: 53: 				[b]Note:[/b] Strings with equal hash values are [i]not[/i] guaranteed to be the same, as a result of hash collisions. On the countrary, strings with different hash values are guarant
895:262: racters of the first page of the ASCII table (values from 0 to 31), such as tabulation ([code]\t[/code]) and newline ([code]\n[/code], [code]\r[/code]) characters, but [i]not[/i] spaces.
doc/classes/StringName.xml: 2
304: 53: 				[b]Note:[/b] Strings with equal hash values are [i]not[/i] guaranteed to be the same, as a result of hash collisions. On the countrary, strings with different hash values are guarant
802:262: racters of the first page of the ASCII table (values from 0 to 31), such as tabulation ([code]\t[/code]) and newline ([code]\n[/code], [code]\r[/code]) characters, but [i]not[/i] spaces.
doc/classes/StyleBoxFlat.xml: 4
149:100: ike [member StyleBox.content_margin_bottom], [member expand_margin_bottom] does [i]not[/i] affect the size of the clickable area for [Control]s. This can negatively impact usability if u
153: 96:  Unlike [member StyleBox.content_margin_left], [member expand_margin_left] does [i]not[/i] affect the size of the clickable area for [Control]s. This can negatively impact usability if u
157: 98: nlike [member StyleBox.content_margin_right], [member expand_margin_right] does [i]not[/i] affect the size of the clickable area for [Control]s. This can negatively impact usability if u
161: 94: b] Unlike [member StyleBox.content_margin_top], [member expand_margin_top] does [i]not[/i] affect the size of the clickable area for [Control]s. This can negatively impact usability if u
doc/classes/Vector3.xml: 1
273:127: n only be used for [method normalized] vectors. [method octahedron_encode] does [i]not[/i] check whether this [Vector3] is normalized, and will return a value that does not decompress to
doc/classes/Viewport.xml: 1
348:127: essing filter to make banding significantly less visible in 3D. 2D rendering is [i]not[/i] affected by debanding unless the [member Environment.background_mode] is [constant Environment.
modules/csg/doc_classes/CSGPolygon3D.xml: 1
 51:146:  This can be a convex or concave polygon with 3 or more points. The polygon must [i]not[/i] have any intersecting edges. Otherwise, triangulation will fail and no mesh will be generated.

italic "must" - 14 matches
doc/classes/CPUParticles3D.xml: 4
129:177: ffect on a [BaseMaterial3D], [member BaseMaterial3D.vertex_color_use_as_albedo] [i]must[/i] be [code]true[/code]. For a [ShaderMaterial], [code]ALBEDO *= COLOR.rgb;[/code] must be inserte
133:190: ffect on a [BaseMaterial3D], [member BaseMaterial3D.vertex_color_use_as_albedo] [i]must[/i] be [code]true[/code]. For a [ShaderMaterial], [code]ALBEDO *= COLOR.rgb;[/code] must be inserte
137:182: ffect on a [BaseMaterial3D], [member BaseMaterial3D.vertex_color_use_as_albedo] [i]must[/i] be [code]true[/code]. For a [ShaderMaterial], [code]ALBEDO *= COLOR.rgb;[/code] must be inserte
159:187: ffect on a [BaseMaterial3D], [member BaseMaterial3D.vertex_color_use_as_albedo] [i]must[/i] be [code]true[/code]. For a [ShaderMaterial], [code]ALBEDO *= COLOR.rgb;[/code] must be inserte
doc/classes/GeometryInstance3D.xml: 1
 25: 84: 	[b]Note:[/b] For a shader uniform to be assignable on a per-instance basis, it [i]must[/i] be defined with [code]instance uniform ...[/code] rather than [code]uniform ...[/code] in the s
doc/classes/ImageTextureLayered.xml: 1
 16:218: data format. The first image decides the width, height, image format and mipmapping setting. The other images [i]must[/i] have the same width, height, image format and mipmapping setting.
doc/classes/Object.xml: 1
212:183: ng custom properties, which is particularly useful for editor plugins. Note that a property [i]must[/i] be present in [method get_property_list], otherwise this method will not be called.
doc/classes/ParticleProcessMaterial.xml: 4
134:177: ffect on a [BaseMaterial3D], [member BaseMaterial3D.vertex_color_use_as_albedo] [i]must[/i] be [code]true[/code]. For a [ShaderMaterial], [code]ALBEDO *= COLOR.rgb;[/code] must be inserte
138:190: ffect on a [BaseMaterial3D], [member BaseMaterial3D.vertex_color_use_as_albedo] [i]must[/i] be [code]true[/code]. For a [ShaderMaterial], [code]ALBEDO *= COLOR.rgb;[/code] must be inserte
142:182: ffect on a [BaseMaterial3D], [member BaseMaterial3D.vertex_color_use_as_albedo] [i]must[/i] be [code]true[/code]. For a [ShaderMaterial], [code]ALBEDO *= COLOR.rgb;[/code] must be inserte
161:194: ffect on a [BaseMaterial3D], [member BaseMaterial3D.vertex_color_use_as_albedo] [i]must[/i] be [code]true[/code]. For a [ShaderMaterial], [code]ALBEDO *= COLOR.rgb;[/code] must be inserte
doc/classes/ProjectSettings.xml: 1
2661: 16: 			The texture [i]must[/i] use a lossless compression format so that colors can be matched precisely. The following VRS densities are mapped to various colors, with brighter colors repres
doc/classes/ResourceImporterTextureAtlas.xml: 1
 14: 40: 			Path to the atlas spritesheet. This [i]must[/i] be set to valid path to a PNG image. Otherwise, the atlas will fail to import.
doc/classes/Viewport.xml: 1
367: 16: 			The texture [i]must[/i] use a lossless compression format so that colors can be matched precisely. The following VRS densities are mapped to various colors, with brighter colors repres

It raises the mathematical constant [b]e[/b] to the power of [param x] and returns it.

The mathematical constant 𝑒 is usually italic. I think it should be [i] as long as it's not referring to something in code.

go to the [b]Sprite2D[/b] menu

This is referring to the text on the menu button. I don't think it should be [code], but I'm not sure whether it should be [i] or [b].

[b]Tap2[/b] delay time in milliseconds.

Judging from the context, although related the function's name, it's just a stylized "Tap 2", or second tap. I think [code]tap2[/code] should be changed to plain tap 2 or [b]tap 2[/b].

Judging from the context, although related the function's name, it's just a stylized "Tap 2", or second tap.

I think it's just capitalized because it's at a start of a sentence 🙃 Though the sentence itself is poorly phrased, IMO. I don't mind if we fix it, and if we replace tap2 with "the second tap".

Added the following changes:

Use [i] for mathematical constant "e".
Use [b] for button text & menu item text. Because only Area3D uses [i] for this.
Replace "tap1" and "tap2" to "the first tap" and "the second tap" accordingly.

Thanks!

authors: YuriSizov dalexeev timothyqiu


text:
[4.2] Fix Audio track crossfade in AnimationPlayer does not work

Cherry-pick from https://github.com/godotengine/godot/pull/86715.
This is an exaggeration. The old AnimationPlayer only deleted the caches for the AudioTrack and AnimationPlaybackTrack.
And now that the AudioTrack is properly managed for blending, there should be no need to delete the cache here so clearing AnimationPlaybackTrack is only needed.

Thanks!

authors: TokageItLab YuriSizov


text:
Do overflow check in when gererating NoiseTexture3D

An idea of fixing https://github.com/godotengine/godot/issues/88800
The origin problem is that the MRP's NoiseTexture3D's width is 4096, height is 4096 and depth is 4096. And In Noise::_get_image it will call values.resize(p_width * p_height * p_depth), the values vector's capacity is uint32_t which can not handle 4096^3 and overflows, thus the resize failed, or more preciously speaking, it overflowed to 0, and the later vector indexing caused this crash.
My solution here, technically speaking is not overflow check but more like an sanity check (the limit here is arbitray but can be less smaller since it has to be uploaded to gpu) that should be placed somewhere in NoiseTexture3D, I'm not sure where is the best place to do it or what's godot's way of handling such behaviour. Feel free to correct me.
Also the NoiseTexture2D may need the same check too, although it's less likely to have the same problem as NoiseTexture3D.

Limits it to the same memory size that maximum 2d texture has, looks good 👍

Thanks!

authors: akien-mga emre0altan jsjtxietian


text:
Add optional param cancel_sliding to move_and_collide

This PR exposes the p_cancel_sliding as a parameter to move_and_collide in ClassDB (which GDScript uses). This makes it possible to specify either to cancel sliding or not.
As @smix8 said in the proposal:

The problem here is more the method binding, e.g. GDScript users think they are calling move_and_collide() but what they are really calling is a _move() wrapper function that omits parameters.

Open questions
Currently, there's a discrepancy between 2D and 3D in the cancel_sliding default values. The original C++ move_and_collide p_cancel_sliding parameters change between versions (being true on 2D, and false on 3D).
I chose to keep that default behavior for the exposed ClassDB move_and_collide, but maybe it should be better to expose the same default for end-users.
(update: it was me that caused that discrepancy but didn't realized it. Thank you @AThousandShips!)
MRP
cancel-sliding.zip
Fixes
Fixes godotengine/godot-proposals#9253

It seems like merging is blocked due to failed checks for the linux editor.

Indeed. It's because the extra argument makes this a breaking change (at least for GDExtension). It would need a compatibility method (wouldn't know how to do it right now).

I'm on it. This PR slipped between my cracks, sorry!

Can this make the cut for 4.3 still? Unsure, but worth noting.

authors: Mickeon adamscott yosoyfreeman