text:
Wrong PointLight2D position on parallax layers when camera is active

Godot version
v4.0.alpha12.official [2c11e6d9e]
System information
macOS, Linux and Windows 10
Issue description
The PointLight2D position on parallax layers is off when a camera is active.
In my example, a flashlight is attached to the player.
When camera is disabled the light illuminate the parallax layer at the right position:

When camera is enabled the light position is off:

Video of the minimal reproduction project:
https://user-images.githubusercontent.com/1422403/179389256-7b54426c-4857-4525-87da-0ed712e618e9.mov
Steps to reproduce
How to use the minimal reproduction project:

'arrows' to move player
'enter' to toggle on/off the camera

Minimal reproduction project
parallax-light2d-camera-bug.zip

Can you reproduce this with the same setup on 3.4.4?

@Calinou on 3.4.4 it works correctly.
I found this issue while porting a project from 3.4 to 4.0

source: gharchive/issue

authors: Calinou Cowa

repo: godotengine/godot

license: MIT

license_type: permissive

license_source: github-api


text:
Copy & pasting nodes into a child scene with "Editable Children" does not work correctly

Godot version
3.5.stable
System information
Linux. OpenGL ES 3.0. AMD Radeon RX 6700 XT
Issue description
I have a child scene with "Editable Children" and I can create new nodes within the child scene via the parent scene.
What does not work is pasting a node into the expanded child scene.
What looks to happen is that it thinks the pasted node is actually inherited from the child scene and doesn't actually create the copied node into the parent scene. I think this because it appears grey like the other inherited nodes. It also does not save. If you close and reopen the parent scene the pasted node is lost. It is also lost if you run the project.
Steps to reproduce
Copy the Light2D

Paste it into one of the inherited nodes

Minimal reproduction project
EditableChildrenCopyPasteMRP.zip

Same bug in Godot 4.0.2
(v4.0.2.stable.mono.official [7a0977ce2] )

authors: HowQi tehsquidge


text:
Crash when opening project after unify build PR

Godot version
e69b7083d45c5d8698508cce7086d361c4b1f44c
System information
Manjaro linux
Issue description
ps: this is the fisrt build for mono after: https://github.com/godotengine/godot/pull/66242/
when opening the project this crash report happens:
The specified runtimeconfig.json [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/bin/GodotSharp/Api/Debug/GodotPlugins.runtimeconfig.json] does not exist
ERROR: hostfxr_initialize_for_runtime_config failed with code: -2147450733
   at: initialize_hostfxr_for_config (modules/mono/mono_gd/gd_mono.cpp:201)
ERROR: Parameter "load_assembly_and_get_function_pointer" is null.
   at: initialize_hostfxr_and_godot_plugins (modules/mono/mono_gd/gd_mono.cpp:274)
ERROR: Parameter "godot_plugins_initialize" is null.
   at: initialize (modules/mono/mono_gd/gd_mono.cpp:403)

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.beta.mono.custom_build (e69b7083d45c5d8698508cce7086d361c4b1f44c)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /usr/lib/libc.so.6(+0x38a40) [0x7fb2813e9a40] (??:0)
-- END OF BACKTRACE --
================================================================

this is the build message:
Running MSBuild:  /usr/bin/dotnet msbuild /run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotSharp.sln /restore /t:Build /p:Configuration=Debug /p:NoWarn=1591 /p:ClearNuGetLocalCache=true /p:PushNuGetToLocalSource=/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/CustomNuget
Microsoft(R) Build Engine versão 17.0.0+c9eb9dd64 para .NET
Copyright (C) Microsoft Corporation. Todos os direitos reservados.

  Determining projects to restore...
  Restored /run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotPlugins/GodotPlugins.csproj (in 79 ms).
  Restored /run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotSharpEditor/GodotSharpEditor.csproj (in 79 ms).
  Restored /run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotSharp/GodotSharp.csproj (in 100 ms).
  Restored /run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/Godot.SourceGenerators.Internal/Godot.SourceGenerators.Internal.csproj (in 145 ms).
/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotSharp/GodotSharp.csproj(139,3): error MSB4019: o projeto importado "/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotSharp/Generated/GeneratedIncludes.props" não foi localizado. Confirme se a expressão na declaração Import "Generated/GeneratedIncludes.props" está correta e se o arquivo existe no disco.
/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotSharpEditor/GodotSharpEditor.csproj(41,3): error MSB4019: o projeto importado "/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotSharpEditor/Generated/GeneratedIncludes.props" não foi localizado. Confirme se a expressão na declaração Import "Generated/GeneratedIncludes.props" está correta e se o arquivo existe no disco.
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018: Falha inesperada da tarefa "ResolvePackageAssets". [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotPlugins/GodotPlugins.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018: NuGet.Packaging.Core.PackagingException: Unable to find fallback package folder '/home/nonunknown/.local/share/godot/mono/GodotNuGetFallbackFolder'. [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotPlugins/GodotPlugins.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at NuGet.Packaging.FallbackPackagePathResolver..ctor(String userPackageFolder, IEnumerable`1 fallbackPackageFolders) [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotPlugins/GodotPlugins.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.NET.Build.Tasks.NuGetPackageResolver.CreateResolver(IEnumerable`1 packageFolders) [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotPlugins/GodotPlugins.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.NET.Build.Tasks.NuGetPackageResolver.CreateResolver(LockFile lockFile) [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotPlugins/GodotPlugins.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheWriter..ctor(ResolvePackageAssets task) [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotPlugins/GodotPlugins.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheReader.CreateReaderFromDisk(ResolvePackageAssets task, Byte[] settingsHash) [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotPlugins/GodotPlugins.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheReader..ctor(ResolvePackageAssets task) [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotPlugins/GodotPlugins.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResolvePackageAssets.ReadItemGroups() [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotPlugins/GodotPlugins.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResolvePackageAssets.ExecuteCore() [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotPlugins/GodotPlugins.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.NET.Build.Tasks.TaskBase.Execute() [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotPlugins/GodotPlugins.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotPlugins/GodotPlugins.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/GodotPlugins/GodotPlugins.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018: Falha inesperada da tarefa "ResolvePackageAssets". [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/Godot.SourceGenerators.Internal/Godot.SourceGenerators.Internal.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018: NuGet.Packaging.Core.PackagingException: Unable to find fallback package folder '/home/nonunknown/.local/share/godot/mono/GodotNuGetFallbackFolder'. [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/Godot.SourceGenerators.Internal/Godot.SourceGenerators.Internal.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at NuGet.Packaging.FallbackPackagePathResolver..ctor(String userPackageFolder, IEnumerable`1 fallbackPackageFolders) [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/Godot.SourceGenerators.Internal/Godot.SourceGenerators.Internal.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.NET.Build.Tasks.NuGetPackageResolver.CreateResolver(IEnumerable`1 packageFolders) [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/Godot.SourceGenerators.Internal/Godot.SourceGenerators.Internal.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.NET.Build.Tasks.NuGetPackageResolver.CreateResolver(LockFile lockFile) [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/Godot.SourceGenerators.Internal/Godot.SourceGenerators.Internal.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheWriter..ctor(ResolvePackageAssets task) [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/Godot.SourceGenerators.Internal/Godot.SourceGenerators.Internal.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheReader.CreateReaderFromDisk(ResolvePackageAssets task, Byte[] settingsHash) [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/Godot.SourceGenerators.Internal/Godot.SourceGenerators.Internal.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheReader..ctor(ResolvePackageAssets task) [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/Godot.SourceGenerators.Internal/Godot.SourceGenerators.Internal.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResolvePackageAssets.ReadItemGroups() [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/Godot.SourceGenerators.Internal/Godot.SourceGenerators.Internal.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResolvePackageAssets.ExecuteCore() [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/Godot.SourceGenerators.Internal/Godot.SourceGenerators.Internal.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.NET.Build.Tasks.TaskBase.Execute() [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/Godot.SourceGenerators.Internal/Godot.SourceGenerators.Internal.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/Godot.SourceGenerators.Internal/Godot.SourceGenerators.Internal.csproj]
/usr/share/dotnet/sdk/6.0.108/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [/run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/godot/modules/mono/glue/GodotSharp/Godot.SourceGenerators.Internal/Godot.SourceGenerators.Internal.csproj]
scons: Reading SConscript files ...
Warning: Speech Dispatcher development libraries not found. Disabling Text-to-Speech support.
Building for platform "linuxbsd", architecture "x86_64", target "editor.
Checking for C header file mntent.h... (cached) yes
scons: done reading SConscript files.
scons: Building targets ...
[100%] progress_finish(["progress_finish"], [])
[100%] scons: done building targets.
[Time elapsed: 00:00:08.626]
./compile_mono.sh: linha 9: ./bin/godot.linuxbsd.tools.x86_64.mono: Arquivo ou diretório inexistente

Steps to reproduce
build settings:
compile_mono.sh
cd godot
git switch master
git pull
scons p=linuxbsd tools=yes module_mono_enabled=yes mono_glue=no target=editor -j12
bin/godot.linuxbsd.tools.x86_64.mono --generate-mono-glue modules/mono/glue
./modules/mono/build_scripts/build_assemblies.py --godot-output-dir ./bin \
    --push-nupkgs-local /run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/CustomNuget/
scons p=linuxbsd target=editor tools=yes module_mono_enabled=yes -j12
./bin/godot.linuxbsd.tools.x86_64.mono -v

Minimal reproduction project
N/a

You're running the wrong build. Please read the description of the PR you linked :)

authors: akien-mga nonunknown


text:
Game crashes/freezes the entire computer (Linux and Windows)

Godot version
4.0 dev Beta 9+
System information
Arch Linux + Radeon RX6800XT, Windows 10 + GeFore GTX 1060
Video demonstration
https://youtu.be/m8zEIOnCss4
Issue description
In recent beta versions of Godot 4 me and other users of my game are experiencing entire desktop crashes. For me it's an X11 session crash that restarts the X server, for another user it's their Windows PC freezing and requiring a power cut to reboot.
Here's a dmesg log from my system after one such event when Godot 4 Beta 9 crashed when I caused the game to render a lot of particles. A ver ysimilar dmesg log can be seen in the above video with Beta 10 when merely attempting to start a game.
dmesg.log
Here's what a user reported to me when testing with Beta 10:

Downloaded Beta 10 -> Opened Liblast project -> started game -> PC Froze -> Removed pc from plug to restart... 😢
Tried again after deleting .godot dir... still freezes my pc...
I'm on windows... I tried gl_compatibility render... opengl... it runs but then shaders break...

Steps to reproduce

Clone the Liblast project with LFS (instructions: https://codeberg.org/Liblast/Liblast#_how_to_edit_the_game)
Get Godot 4 Beta 10
Load the Liblast project
Start the game
Desktop crash / computer freeze?
if not - stop the game and retry

Minimal reproduction project
I am afraid I don't have one :(

@unfa If the issue is new with Godot 4 beta 10, could you try to bisect the regression? It could help, at least, to create a MRP if the culprit commit is found.

Hi... I was the one being mentioned... this is my specs if it helps...

And these errors shows but doesn't seem to indicate what files/nodes/script are causing the problem...

@adamscott I'll try to do that, though I might take a while.

@mamarilmanson I think the tween error spam is not related, as I've seen that for a good while before we've had these system crashes/freezes.

@unfa I did not mean it to be related to the crash... I just wish there was a way to trace why and where the errors are triggering... :)

authors: adamscott mamarilmanson unfa


text:
CollisionShape2D scale() not working?

This is my node hierarchy:

Hierarchy:
RigidBody2D
  Sprite
  CollisionShape2D

I'm trying to scale down the Rigidbody2D node (Flame node):

This is how I'm doing it. Sprite nodes scales down when I scale its parent down, but the Collision node does not.
Which is strange, because , if I do this in the graphical editor, everything scales perfectly fine, including the CollisionShape2D.
So I realise that I can't change CollisionShape2D size with the scale() method.
But how else can I scale a node with a CollisionShape2D?, I tried to to code within the CollisionShape2D node, it doesn't work either. So what can I do to dynamically shrink the Node with a collision?
Someone on IIRC told me to swap with 2 collision, but is that really the only way?
Link to minimal example project (optional but very welcome):
Fire.zip

I think is duplicated of #5734
Apart from that, CollisionShape is a helper, wont scale the body's shapes or do anything other than add editor and debug tools.
You will have to scale the shape resources manually (get/set shape) and children (shapes are not children) instead of the body until Godot 3.x changes something on the way shapes are managed.

I basically replaced it with KinematicBody2D.
I actually don't see the purpose of RigidBody2D... it's not programmeable in runtime, while the KinematicBody2D is.

Duplicate of #5734 indeed.

authors: Qws akien-mga eon-s


text:
Infinite Import Loop Bug with renaming folders with blend-files inside

Godot version
v4.2.dev.custom_build [75f9c97de]
System information
Linux. However this should not matter here ...
Issue description
Renaming Folders with Blender-Files inside does not work.
The result is an infinite loop of trying to import the blender models searching the models still on the old path and not the updated one.
E.g. using my project:
https://github.com/nano13/GodotFirstPersonController/blob/main/README.md
And trying to rename the folder Models to models gives error messages like these in the console:
ERROR: Can't find file 'uid://c2xnrl0gkw8ix::::res://Models/textures/dv222.tga'.
   at: _reimport_file (editor/editor_file_system.cpp:1937)
ERROR: Can't find file 'uid://cqce5bblylj5e::::res://Models/textures/intlights222.tga'.
   at: _reimport_file (editor/editor_file_system.cpp:1937)
ERROR: Can't find file 'uid://c82vttiixik57::::res://Models/textures/drevco222.tga'.
   at: _reimport_file (editor/editor_file_system.cpp:1937)
ERROR: Can't find file 'uid://d0mq5yjphyh8s::::res://Models/textures/leather222tga.tga'.
   at: _reimport_file (editor/editor_file_system.cpp:1937)
ERROR: Can't find file 'uid://dkqxa3anhto25::::res://Models/textures/velbag222tga.tga'.
   at: _reimport_file (editor/editor_file_system.cpp:1937)

Which is true as the folder name Models in the path has not been updated, but the folder is actually renamed
(I will however try to fix this issue for my example project by manually renaming the path in all the configs)
Steps to reproduce
Checkout my project from the URL above, and try to rename the folder called Models/models.
Minimal reproduction project
See the URL above.

Thank you for reporting, please add the specific commit hash to your issue description, "latest" moves constantly

In the import-files, e.g. models/mercedes_s500_wheel.blend.import it did not update the renamed folder Materials to materials either ...

After fixing the blender-issue (https://github.com/godotengine/godot/issues/76338) by upgrading to blender 3.6.1 this seems not to be a problem anymore.
So as far as I can currently tell, it would be safe to close this issue now.

After fixing the blender-issue (https://github.com/godotengine/godot/issues/76338) by upgrading to blender 3.6.1 this seems not to be a problem anymore.
So as far as I can currently tell, it would be safe to close this issue now.


text:
Area3D doesn't detect any bodies if it's fully inside them

Godot version
4.1.1
System information
Windows 10
Issue description
When an Area3D is fully inside another object, it doesn't detect as overlapping with that object. It's actually causing a bit of a problem when trying to detect if a rigidbody is on the ground.
Steps to reproduce
Create an Area3D, attach a script to it, and print from _process or _physics_process get_overlapping_bodies()
Put it partially inside an object, and it'll print that object no problem
Put it all the way inside, and it'll print nothing
Minimal reproduction project
N/A

Please provide a minimal reproduction project to make this easier to test:

A small Godot project which reproduces the issue, with no unnecessary files included. Be sure to not include the .godot folder in the archive (but keep project.godot).
Drag and drop a ZIP archive to upload it. Do not select another field until the project is done uploading.
Note for C# users: If your issue is not Mono-specific, please upload a minimal reproduction project written in GDScript or VisualScript. This will make it easier for contributors to reproduce the issue locally as not everyone has a Mono setup available.

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

I'm currently having this issue too.
Area3D.has_overlapping_bodies() seems to only detect when it intersects with a collider and never when the Area3D is completely inside a collider.
Moving an Area3D inside of a collider with no intersecting edges, and then checking has_overlapping_bodies() always returns false from my testing.
It would be great if this issue could be re-opened for further testing and inspection by the community.

authors: AThousandShips CammiePone dicemaster5


text:
TextureRect Stretching Breaks With SubViewport

Godot version
v4.1.1.stable.official [bd6af8e0e]
System information
Godot v4.1.1.stable - Gentoo 2.14 - Vulkan (Compatibility) - AMD Radeon Vega 8 Graphics (raven, LLVM 16.0.6, DRM 3.49, 6.1.53-gentoo-r1-x86_64) () - AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx (8 Threads)
Issue description
When I create a TextureRect background that repeats a smaller texture, then place a SubViewportContainer and Subviewport, the TextureRect glitches.

Steps to reproduce

Add a TextureRect with stretch_tile and expand_keep_size.
Add a SubViewportContainer and SubViewport.

However, this may be an issue with compatibility mode or my specific settings, so please run the attached project. Uncomment the lines at the bottom of game.gd for my work-around.
Minimal reproduction project
bug.zip

I've tried all the different texture_repeat settings. They had no effect. However, if I preload the texture instead of loading, it works fine.

Looks correctly for me.

Try in 4.2 dev. Might be broken in older version.

Looks like it's fixed. Thanks.

authors: KoBeWi duane-r


text:
[beta 3] GPU Particle 2D damping works incorrectly

Godot version
v4.2.beta3.official [e8d57afae]
System information
Godot v4.2.beta3 - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3080 (NVIDIA; 31.0.15.4592) - AMD Ryzen 9 5900X 12-Core Processor (24 Threads)
Issue description
After upgrading to beta 3, some of my particles which have fixed velocity no longer move at all - they just spawn and stay, with damping set to 150-200 (min-max) and initial velocity of 160-160.
According to description (and to how it works in beta 2), those settings should mean that my particles are moving but will be slowed to 0 within 0.6-1s approx.
In beta 3, setting damping to just 10 is enough for my particle to not move at all. Does not happen in beta 2.
If behaviour / meaning of damping value was changed, this needs to be reflected in the documentation as well, otherwise it's a bug?
How it now works in beta 3:
https://github.com/godotengine/godot/assets/43399078/9ab05d4d-9cbb-4cbf-8a07-bb2b67e304fd
How it's supposed to work (and was working in beta 2):
https://github.com/godotengine/godot/assets/43399078/cc614804-9a5f-4054-bd4a-bec252e95058
FPS is low due to ShareX recording being considered as alt-tabbed, but should still be fairly obvious what's wrong.
Particle with material etc attached.
Steps to reproduce

Create GPUParticle2D
Add ParticleProcessMaterial
Remove gravity, set Initial velocity min/max to something high (1000 will do)
Set damping under Acceleration to 15 / 15 (min / max) - emitted particles no longer moves.

Minimal reproduction project
Attaching just the particle scene, as it's self-contained
thruster_1.zip

Should be addressed by https://github.com/godotengine/godot/pull/84028

Duplicate of #84009.

authors: QbieShay SanctusAnimus akien-mga


text:
Race condition in RichTextLabel

Tested versions
4.2.1
System information
Windows 10, Godot 4.2.1, Gles3 compatibility
Issue description
There seems to be a race condition in RichTextLabel when using threaded updates. I got multiple crash dumps from users that crash in RichTextLabel::_process_line_caches on the line
Rect2 text_rect = _get_text_rect();

with an access fault on theme_cache.normal_style->get_offset() with normal_style seeming to be a nullptr.
My best guess is that the thread callback created here starts before task gets assigned
if (threaded) {
	updating.store(true);
	loaded.store(true);
	task = WorkerThreadPool::get_singleton()->add_template_task(this, &RichTextLabel::_thread_function, nullptr, true, vformat("RichTextLabelShape:%x", (int64_t)get_instance_id()));
	set_physics_process_internal(true);
	loading_started = OS::get_singleton()->get_ticks_msec();
	return false;
}

leading this check on task here to fail causing the destructor to not wait for the background task to complete.
void RichTextLabel::_stop_thread() {
	if (threaded) {
		stop_thread.store(true);
		if (task != WorkerThreadPool::INVALID_TASK_ID) {
			WorkerThreadPool::get_singleton()->wait_for_task_completion(task);
			task = WorkerThreadPool::INVALID_TASK_ID;
		}
	}
}

Steps to reproduce
Unload RichTextLabels with threaded set to true
Minimal reproduction project (MRP)

Unload RichTextLabels with threaded set to true

How exactly it's unloaded, via queue_free() or something else? Normally, it should cancel the task long before destructor is called.

All the crashdumps I got happend on map/scene change. We change scenes by calling a deferred method that then calls free not queue_free to free the whole scene before loading the next one.


text:
Syntax Highlighting for custom type hints fails after linebreaks in parameter list

Tested versions
4.2.1
System information
Windows 10, Godot 4.2.1, Gles3 compatibility
Issue description
When adding typehints to function declarations the highlighting stops working if linebreaks are added:

Steps to reproduce
Write a function with type hints for some custom types. Add linebreaks in the parameter list
Minimal reproduction project (MRP)

This has been not been fixed in master (currently 4.3).

Custom type hints, it's worth noting. It seems like https://github.com/godotengine/godot/pull/86176 does not handle this edge-case (CC @dalexeev).

This is difficult to fix without a major refactoring of the highlighter. For each new line, the context is lost (with the exception of code regions).

Wouldn't it make sense to keep the context for the current state ment atleast? I.e. if inside brackets you dont discard on linebreak.

authors: 0x0ACB Mickeon dalexeev


text:
GDExtension classes inheriting from Resource are not using icons in FileSystem

Tested versions
4.3 dev 1
System information
Windows 10 Godot 4.3 dev 1 Vulkan
Issue description
I am aware there is https://github.com/godotengine/godot/issues/32706, but it does not seem to cover GDExtensions.
Currently, GDExtension classes inheriting from Resource are not using icons in FileSystem. It seems to work in every other place, but not in FileSystem for some reason.

Steps to reproduce

Create a class in GDExtension that inherits Resource
Assign an icon in .gdextension file to said class
Observe how FileSystem is using default icon for this class, while the property viewer is displaying everything as expected

Minimal reproduction project (MRP)
You can see an example in the root of the project here

IconTest.zip

I tested it and found the same problem when using gdscript to inherit resource subclasses.

authors: SaNeOr Withaust


text:
Fix box selection to in canvas and spatial editor.

Fixes bug with the box selection where rendered box's shape gets inverted if you move the cursor left or above its origin point.

See also #10897, cc @bojidar-bg. Both PRs look a bit hackish, are they really the proper fix for the regression introduced by #10417?

I personally prefer the other PR, the fix shouldn't be done in every place draw_rect is called.
The problem is that prior to #10417, negative destination rectangles were allowed, but after it, negative size was used for encoding transpose.
#10897 fixes the issue by just ensuring positive size right before sending it to the shader.
This PR fixes the issue by ensuring positive size is being sent to the VisualServer.
IMO, we should change the rasterizer, since otherwise people might start abusing the undocumented feature that draw_rect(…Rect2(0, 0, -100, 100)…) would draw a transposed texture when using the gles3 rasterizer.

Well, I don't really have any input on how it should best be fixed. Either way would probably be fine.

Superseded by #10897.

source: gharchive/pull-request

authors: SaracenOne akien-mga bojidar-bg


text:
Work around a GCC optimizer bug at -O3

This bug has been reported upstream, once it gets fixed we'll add some
version guards to only disable this for specific GCC versions.
This fixes #19633

Not cherry-picking as it's superseded by #25115.

For the record, can someone link the GCC bug?

Given that @hpvb wrote:

This bug has been reported upstream

I checked GCC bugs reported on Jan 17 or 18, 2019, but I don't see any that looks like our issue. I guess he found a reference to a pre-existing bug report and omitted to include the link.

authors: aaronfranke akien-mga hpvb


text:
Fix text_edit drawing incorrect chars when syntax highlighting enabled

Fixes text_edit drawing incorrect characters when syntax highlighting is enabled, it now works the same way as having the setting disabled. I believe this is left over from before the syntax highlighter was extracted.
closes #28860

Cherry-picked for 3.1.2.


text:
Fixed Make 3D viewport locked nodes unselectable as in 2D viewport

Fixes #29903  . 3D viewport nodes cannot be selected when they are locked.

Thanks and congrats for your first contribution! :)

Thank you for your support and for giving me this opportunity.

authors: akien-mga n-k-chilagani


text:
[Vulkan, macOS] Fix RID leaks and crashes on exit.

Move Vulkan context and rendering_device destruction from OS::finalize() (called after window and underlying Metal layer are closed) to windowWillClose() notification to prevent RID leaks and double frees on exit.

Thanks!

authors: akien-mga bruvzg


text:
Add duplicate track action to AnimationPlayer

The PR #24210 was originally made by PedroHugoNoevo, and this PR is his commit applied to Godot 3.2-stable.
Original commit by: PedroHugoNoevo
Original PR:

This solves issue #15029

I created this PR because he hasn't interacted with the original PR since December 2018 and this seems to be able to benefit a lot of users according to the issue's +1s.
Bugsquad edit: Fixes #15029.

Needs a rebase on the current master branch (and likely changes / testing to ensure that it still works).

This kind of things should not need a popup window to be able to duplicate things. Ideally you would do: select the tracks, right-click, then duplicate. You should not need a another popup to select the tracks.
I'm not against the merge since it's better than not being able to duplicate, but the UI proposed here is quite bad.

would it be possible to have the "duplicate tracks" feature merged anytime soon? Looks like I would have to redo manually lots of key frames otherwise.

Dead PR? No pushes in ages - Akien's comments not resolved.
Doesn't look to be a difficult change to make. I also agree with groud that the second popup seems unnecessary.

Closing per @EricEzaM's comment. This PR can be salvaged by anyone as desired.

authors: Calinou EricEzaM abayerle1 akien-mga groud jahd2602


text:
Perform a clean Gradle build if android plugins changed

Fixes #38986
To check if a plugin has been part of the previous build i check if it appears in the manifest merger logs in build/outputs/logs/. If it has been enabled/disabled since the last build i do a clean Gradle build, which deletes the android/build/build directory.
Note, that i only tested this on the 3.2 branch, but since there is no difference between master and 3.2 i directly opened this PR against master.

@mbrlabs This seems to do the job partially as the logic doesn't check for changes to the plugin dependencies (both local and remote ones) in the manifest merger logs.
I wonder though if it would be easier and simpler to compare the last updated timestamp instead.
We can add a last_updated field to the PluginConfig struct and at load time (the logic used by get_plugins()) fill it with the value of the last updated component of the plugin:

Start with the last update time for the plugin configuration file.
If any of the plugin binary or local dependencies has a more recent updated timestamp, use that instead.

Then at export time, check the last update timestamp of the build directory with the ones from the enabled plugins. As soon as one of the enabled plugins is newer, perform a clean build.
To check for added/removed plugins, we can store in memory the list of plugins' names used in the last build, and compare with the current build.

Right, i didn't consider the plugin's dependencies. Your solution sould be easy to implement. I'm going to have a shot at it tomorrow.
Concerning the check for enabled/removed plugins: I thought about doing it in-memory at first as well, but then went for the logfile checks because it's not garanteed that the user made a build before enabling/disabling plugins in the editor...so it might not be in memory.

Concerning the check for enabled/removed plugins: I thought about doing it in-memory at first as well, but then went for the logfile checks because it's not garanteed that the user made a build before enabling/disabling plugins in the editor...so it might not be in memory.

In that scenario, we can just default to having a clean build similarly to the logic you have when unable to open the log files.
In practice, this should only affect the first build after the editor has been opened. It seems like good practice to always have the first build be a clean build.

@m4gr3d Done.
One thing tough: It's not possible to check the modification time of a folder (at least not in Windows) if no files have been added/removed directly, so instead of checking a particular file i used an in-memory last_custom_build_time field which is initially set to 0 and also makes sure that the first build is always a clean build.

I don't know whats going on with the static analysis checks. The last time i updated this PR was because Clang wanted spaces between the comments and values and now i should remove them again?

One thing to notice though is that if the user doesn't use plugins, then the first build won't be a clean build.
We could change that by checking if last_custom_build_time == 0 and triggering the clean build flag, but that may be overkill.
I don't have a preference either way so I'm opened to suggestions.

Checking for  last_custom_build_time == 0 should be fine.

Alright, i pushed the changes. CI checks should be fixed now as well i hope :)

Thanks!

Cherry-picked for 3.2.2.

authors: akien-mga m4gr3d mbrlabs


text:
[WIP] Add basic import shader support

Implements https://github.com/godotengine/godot-proposals/issues/944. Also see https://github.com/godotengine/godot/issues/17303. This salvages https://github.com/godotengine/godot/pull/17797.
The syntax is import "res://new_shader.shader";

Import Shader Project.zip
Example project.
Remaining problems:

Caching is incorrect.
Nested includes needs a better method.

@clayjohn mentioned a proposal to make a new shader type called "include".
shader_type include;
 [It] can only be included by other shaders. It wouldn't be allowed to have render modes or processor functions.

Since you have mentioned #17303 and #17797, do you have any intentions to add preprocessor directives to this PR?

No.
You can use uniforms and variables for #define and if else statements are already in the language.

This needs to be ported to the latest master. It is salvageable, but I am currently lacking effort on it.
The last tasks are to make sure the include detection handles multiple layers correctly.

I am interested in salvaging this. As of right now, I've managed to port the changes to c0d01dcf6185e9090d6b6a1cd7682404d411b72b and at least gotten around import not being recognized as a shader type. I'll admit I'm not too familiar with how the parser works as of yet, but I care enough about this feature to put in the time.

I need this feature too.

@MagdielM did you post your work anywhere?

@MagdielM did you post your work anywhere?

Oh sorry, after three-or-so weeks of trying to get multiple nesting levels to work and not getting very far, other responsibilities started piling up and I had to put this in the backburner for the time being. I apologize for not mentioning this earlier.

@MagdielM did you post your work anywhere?

Oh sorry, after three-or-so weeks of trying to get multiple nesting levels to work and not getting very far, other responsibilities started piling up and I had to put this in the backburner for the time being. I apologize for not mentioning this earlier.

Could you push your code to a branch and link it here? It would likely be helpful if someone is willing to continue this.
Also, I'd argue that even supporting a single level of #include is much better than supporting zero :slightly_smiling_face:

My work includes a small dependency graph that is supposed to update all included shaders, but I couldn't quite figure out why the parser fails to nest the #includes, so ultimately it doesn't do much.
cd198c27a1e9bbdc4fa60d5ae07be3b88ff8f599

authors: Ansraer Calinou CsloudX MagdielM fire


text:
Ignore thread models when compiling with NO_THREAD

The thread model option for physics (2D) and rendering (single-unsafe, single-safe, multithread), was causing crashes/locks when set as multithreaded and exported for a platform that does not support threads (namely HTML5).
This commit ensures that when threads support is not available, that option is ignored, and the equivalent of "single-unsafe" is always used instead.
Fixes #29641

Thanks!

Cherry-picked for 3.2.4.

authors: Faless akien-mga


text:
Fix KinematicBody3D having a duplicate locked_axis variable

Simply put, KinematicBody3D had two different locked_axis variables, which caused incorrect behavior any time they were out of sync. It's a much better idea to only have one variable to track this (like RigidBody3D does), so I deleted the duplicate one.
This fixes #25798 in master, and is the master version of #45176.

https://github.com/godotengine/godot/pull/45176#issuecomment-760344618

https://github.com/godotengine/godot/pull/45176#issuecomment-760344618

#25798 was fixed with #38852, but never backported to 3.2; so this change is not required.
Personally, I think keeping the locked_axis variable in KinematicBody3D is the correct approach. This is the only place it is used. It is not used by the PhysicsServer3D so there is no need to store it there, and, as @AndreaCatania points out, "the physics server API are generally not so fast especially if compared to locked_axis & (1 << i)". The only reason for storing it in PhysicsServer3D would be to keep it consistent with RigidBody3D. The other thing to bear in mind is that the PhysicsServer3D should only be available in _physics_process(). Currently, it doesn't matter, because (in 3D) the physics server doesn't run in its own thread, but we shouldn't be relying on it.
Ultimately, the real problem is the lack of proper syncing between the server and the scene, but that shouldn't be the reason for bypassing that line of separation.

#25798 was fixed with #38852, but never backported to 3.2; so this change is not required.
Personally, I think keeping the locked_axis variable in KinematicBody3D is the correct approach. This is the only place it is used. It is not used by the PhysicsServer3D so there is no need to store it there, and, as @AndreaCatania points out, "the physics server API are generally not so fast especially if compared to locked_axis & (1 << i)". The only reason for storing it in PhysicsServer3D would be to keep it consistent with RigidBody3D. The other thing to bear in mind is that the PhysicsServer3D should only be available in _physics_process(). Currently, it doesn't matter, because (in 3D) the physics server doesn't run in its own thread, but we shouldn't be relying on it.
Ultimately, the real problem is the lack of proper syncing between the server and the scene, but that shouldn't be the reason for bypassing that line of separation.

@madmiraal Then perhaps we should delete the variable in PhysicsServer3D if it's not used there. Either way seems fine to be, but it doesn't make sense to have two variables for the same thing.
I was aware of #38852 when I made this PR (removing the extra code in set_axis_lock is part of this PR), but I don't like that fix at all. I very much disagree with #38852 being backported, there are better fixes available (which is why I opened these PRs). We shouldn't have two variables for the same thing, it's simply a bad idea.

@madmiraal Then perhaps we should delete the variable in PhysicsServer3D if it's not used there. Either way seems fine to be, but it doesn't make sense to have two variables for the same thing.
I was aware of #38852 when I made this PR (removing the extra code in set_axis_lock is part of this PR), but I don't like that fix at all. I very much disagree with #38852 being backported, there are better fixes available (which is why I opened these PRs). We shouldn't have two variables for the same thing, it's simply a bad idea.

We shouldn't have two variables for the same thing, it's simply a bad idea.

The scene-server architecture of Godot requires it. The architecture allows changes to scenes (user interaction) and changes within the server to run in separate threads. Changes are then synced separately. Currently, there is no multi-threading in 3D and the multi-threading in 2D has issues; so it's generally not used. Therefore, it appears as if there is no need to have multiple copies, but that's not actually the case.
This need for separation becomes more obvious, when you consider the more complex scenario of multi-user networked game, where the server runs separately from the players. As I said before:

Ultimately, the real problem is the lack of proper syncing between the server and the scene, but that shouldn't be the reason for bypassing that line of separation.

We shouldn't have two variables for the same thing, it's simply a bad idea.

The scene-server architecture of Godot requires it. The architecture allows changes to scenes (user interaction) and changes within the server to run in separate threads. Changes are then synced separately. Currently, there is no multi-threading in 3D and the multi-threading in 2D has issues; so it's generally not used. Therefore, it appears as if there is no need to have multiple copies, but that's not actually the case.
This need for separation becomes more obvious, when you consider the more complex scenario of multi-user networked game, where the server runs separately from the players. As I said before:

Ultimately, the real problem is the lack of proper syncing between the server and the scene, but that shouldn't be the reason for bypassing that line of separation.

@madmiraal There's no reason to keep two separate variable that are not in sync. RigidBody3D and KinematicBody3D share a variable within the physics server, so the best approach is to keep only the one there.
If you keep the two variables, calling PhysicsServer.body_set_axis_lock for a KinematicBody3D is still not going to work, and we'll have another bug on our hands. So we need to choose the solution that keeps everything in sync here.
The performance hit of these calls to the physics server is negligible compared to the cost of a KinematicBody3D update. Choosing poor design to fix unknown performance issues is not a good idea. An actual issue needs to be identified before finding a solution for it.

@madmiraal There's no reason to keep two separate variable that are not in sync. RigidBody3D and KinematicBody3D share a variable within the physics server, so the best approach is to keep only the one there.
If you keep the two variables, calling PhysicsServer.body_set_axis_lock for a KinematicBody3D is still not going to work, and we'll have another bug on our hands. So we need to choose the solution that keeps everything in sync here.
The performance hit of these calls to the physics server is negligible compared to the cost of a KinematicBody3D update. Choosing poor design to fix unknown performance issues is not a good idea. An actual issue needs to be identified before finding a solution for it.

Forgive me as I'm not really very familiar with the physics, but unless there were good reason to do otherwise I'd tend to agree with @madmiraal . Godot is chocked full of this paradigm, 2 copies of variables, one client side and one on the server, and as I understand it this is the multithread paradigm.
Once you violate it you may be at risk of stalls, or desynchronization, depending on how the queue is implemented. This probably needs @reduz to have a look at and confirm one way or the other.

Yes, after #45852 there's a risk of stalling when in multithreaded mode so I agree it's a good reason to limit the number of calls to the physics server.
For now, porting #38852 to 3.3 is probably the best approach.

@pouleyKetchoupp Thanks for the feedback. This PR is for master so I closed it, but I updated #45176.

authors: AndreaCatania aaronfranke lawnjelly madmiraal pouleyKetchoupp


text:
Improve the editor feature profiles UX (3.x)

3.x version of https://github.com/godotengine/godot/pull/37235.

Add an help message when no profile is selected.

This replaces the class/property trees which are now hidden when no profile is selected.

Display (none) as the current profile when no profile is currently active.
Make the newly created/imported profile the current if it's the first profile to be added to the list.
Make more strings localizable.

Tested on the 3.x branch, it works successfully.
https://github.com/godotengine/godot/commit/fee9742b59f8431fc6dbe2d0e8d3a6c400877c75 is not required to make this PR compile on the 3.x branch.

Thanks!

authors: Calinou akien-mga


text:
Moved disabling bokeh shader variants to before the version_create call

There are two shader variants for the bokeh shader that only apply for the raster version and are disabled in the compute version.
Disabling them has to happen before the version_create call, not after.
Fixes #51696

Thanks!

authors: BastiaanOlij akien-mga


text:
Correctly bind optional arguments when emitting Theme changes

Fixes https://github.com/godotengine/godot/issues/53404, a regression from https://github.com/godotengine/godot/pull/53396. Doesn't seem to be a problem in the 3.x backport, before callables.

Thanks!

authors: akien-mga pycbouh


text:
3.4 Keypad View orientations changed.

I've changed the functionality of the editor's viewport when pressing the keypad 1, 3, and 7 keys (also, of course, the front, right, and top orthogonal views). Before they seemed backwards, except for front and rear views. That is, when pressing keypad 3, the view was actually from the right. With this, it should now be from the left. The same goes for top and bottom. They are now orientated based on the front view.

Thanks for opening a pull request :slightly_smiling_face:
Pull requests (especially ones that break backwards compatibility) should be opened against the master branch instead of 3.x. This is because feature development occurs in the master branch. We can then cherry-pick specific PRs to the 3.x branch if they don't break backwards compatibility.

I see. I changed it according to how the front view works, but it seems the "front" may be "backwards". I simply set it up similar to Blender, because it makes more sense to me, as in Godot everything is based off the front view, so when the go to the right view, it's coming from the right relative from the front view. The same is so with the other views.

It's actually Blender which uses a confusing convention: https://blenderartists.org/t/why-are-front-back-top-bot-views-different-from-left-right-views/1185701
Godot follows the convention established in engineering drawing, see e.g. https://fractory.com/engineering-drawing-basics/ and https://en.wikipedia.org/wiki/Multiview_orthographic_projection
This image from the Blender thread helps visualize it:

Image you're looking at a house, with the observer/camera looking at the "Front" side. If the camera goes towards the right, it's looking at the "Right" side of the house. The house is not an animate object with intrinsic left and right sides like animals have with their limbs, the sides depend from the observer.

It seems like we might make it an option, since it's such a common thing for people to be concerned with? Regardless, I can always just compile my own version without issue, so it'll be easier for me to understand, at least.

It seems like we might make it an option, since it's such a common thing for people to be concerned with? Regardless, I can always just compile my own version without issue, so it'll be easier for me to understand, at least.

Well you can just change the hotkeys in the editor settings.
But in this case I think we should revert to match the Blender behavior which seems correct to me. We just need to make sure we also get Front right, which I'm not sure we do.

I would change the shortcuts but the top view isn't orientated the way I would like, with the front view being on the bottom.

the top view isn't orientated the way I would like, with the front view being on the bottom.

I guess you mean "the front view being on the back" and not "the bottom"? The "bottom view" is something else and perpendicular to the front, back and side views, let's try to be explicit on terminology as it's confusing enough as is :)

The Front view should be the view of a character's front, and the Back view should be of a character's back. Here is a correctly oriented character in the current master with "Front Orthogonal" view:

Having the character face forward (towards -Z) is implied if we accept that +X means right. This orientation is the only way for the character's right hand to be on the right (+X).

Of course, there is some confusion of a camera that is on the right and looking left, vs a camera that is on the left and looking right. In Godot we choose the "on the" sides for the names.

This PR is targeting the 3.4, which is not the right place to change this. It would need to target the master branch so that the change can be applied to all future Godot versions. It could then be backported to 3.x and possibly 3.4 too.
But there's still some discussion needed to really agree on what the view orientation mean and should be. I tend to agree with the proposed change/revert but this should be discussed in a https://github.com/godotengine/godot-proposals so that we can reach consensus and make the change once and for all.

authors: Calinou aaronfranke akien-mga leiget


text:
Fix methods may not be called at the end of the animation.

Previously, the delta could be too small, preventing the methods at the end of the animation from being called.
Fix #61766.

This should make the non-zero delta available to the integral function again.

Although I'm not very familiar with CPP, isn't 0 * delta equal to 0?

When TimeScale is 0, there is case where small deltas are generated continuously.

Isn't this a bug of TimeScale? Or implement restrictions?

Although I'm not very familiar with CPP, isn't 0 * delta equal to 0?

When TimeScale is 0, there is case where small deltas are generated continuously.

Isn't this a bug of TimeScale? Or implement restrictions?

Fix #61853. Reset the internal time while reseek in AnimationNodeAnimation::process.

Superseded by #61885.


text:
Decrease default AudioStreamPlayer2D/3D panning strength

The default panning strength is now more in line with how other engines play positional sound.
This also improves documentation related to the audio panning strength project settings.
See https://github.com/godotengine/godot/pull/58841 where a test project is linked.

I don't see the need for the requested change if there are any, this would nice to have before stable...

Thanks!

authors: Calinou Mickeon akien-mga


text:
Add spacing after newline on editor warning tooltip

While making https://github.com/godotengine/godot/pull/64702, something very minute to most bothered me...
Adds 4 spaces after every newline that isn't followed up by a bullet point, so that the tooltip looks much tidier.

Before
After

Because of the simple implementation, it may not look as nice if a different font were to be used, but even then, it shouldn't be by much.

While at it, might be worth adding another newline after Node configuration warning:, as it looks weird touching the first bullet point when further bullet points are spaced with a separation line.

Tested... Unfortunately, "\t" is ignored because the default tooltip is composed by a PopupPanel & Label, and the latter doesn't support tabulation.

and the latter doesn't support tabulation

This may be worth implementing in a separate pull request, as it can be useful when working with a fixed-width font.

@akien-mga Updated tooltip to display an extra newline after "Node configuration warning", but only if there's more than one warning:


text:
Update ru.po

update some missing variable

Thanks, but as mentioned in https://github.com/godotengine/godot/blob/master/tools/translations/README.md, translations are handled on https://hosted.weblate.org/projects/godot-engine/godot/ and should be fixed there, not directly in this git repo. Otherwise it's impossible for me to keep Weblate and git in sync.

authors: akien-mga meirusfandi


text:
Fix roundness of DebugSkipBreakpointsOff icon

I think DebugSkipBreakpointsOff icon is not round enough. With some part cut off it's design lacks unity and feels a little bit unreal. As a home brew game maker and humble contributor I think new one will do better in our icon bundle.

Also please run it through an optimizer and make sure it's just one line of markup inside (with an extra new line at the end).

@adamscott Such a perfect answer! Problem is it would break compability, current icon is not a circle, it's slightly wider than higher. We would need to add some scaling also. :) Not sure if distortion was intentional but I will leave it rather round than circular. :)
@YuriSizov done :)
@akien-mga done :)

@akien-mga Ok, made it perfectly circular. Just want to mention that also removed:
fill-opacity=".996078"
which can be found in few other icons but probably also was not intentional.

but probably also was not intentional.

Indeed, most of the icons relying on this should be normalized (and made sure to use the editor's palette).

Indeed, most of the icons relying on this should be normalized (and made sure to use the editor's palette).

I can grep through the other icons and remove this almost 1 fill-opacity in another PR as it will be very easy to review this way even if hits many files.

Thanks!

authors: YuriSizov akien-mga pkowal1982


text:
Add overrun to EditorPropertyObjectID

Fixes this bug

EDIT:
Added full name in tooltip.

I suggest hiding the middle part of the ID:

It's not supported by the TextServer though.

I mean str_id.left(2) + String::utf8("…") + str_id.right(4).

But then the ID could only be seen in tooltip, even if someone expands the inspector. The text should adjust to the available size.

I don't think this is useful information. Such long numbers are not human readable at all.

Thanks!

authors: KoBeWi akien-mga dalexeev


text:
[3.x] Make AnimationNodeBlendTree use OrderedHashMap insteads Map

3.x version of #79595. Supersedes #79531.
An ordered map must be used.
...I am not familiar with OrderedHashMap, does its order depend on the key? If it does not depend, then StringName is sufficient without making to be a String.

You can use StringName::AlphCompare here as well, check the template for the map

It is sufficient if the order of the inserted order, or the order of the index list of the map depending on the key, is unique.
At least from testing #79595 it seems to work well, but does unique comparison results mean that the order of the index list is unique? @AThousandShips

Pointer comparison means unique order, in one run, and unless the names are freed and reallocated they'll remain ordered, the order doesn't persist between runs though

Looking at the code for Map/RBMap, I see that the comparison by Comparator uniquely determines the index to be stored.
When StringName is used as a key of the Map/RBMap:

When using AlphCompare, the index is uniquely determined by the string
If nothing is specified, the index is determined by comparison of memory address, so if the memory address changes due to restart, etc., the index will change

@AThousandShips Is it correct?

That sounds correct from my experience and reading of the code
My suggestion would be then:

If the order between runs is important (like seems to be the case in 4.x) AlphCompare is good
Otherwise pointer comparison should be preferred as it is significantly more performant

Thanks!

authors: AThousandShips TokageItLab akien-mga


text:
模板引擎-模板函数-内置函数-减法(minus) 计算结果错误

减法计算结果不正确
{{.num1 | minus .num2}}
.num1=4
.num2=2
当前给出结果(错误结果)=-2
正确结果=2
除法计算结果不正确
{{.num1 | divide .num2}}
.num1=4
.num2=2
当前给出结果(错误结果)=0.5
正确结果=2
猜测是变量顺序反了,但是使用文档里面是举例中的顺序

@x-controller 你好，感谢反馈，这里是文档示例问题，已更新文档：https://goframe.org/pages/viewpage.action?pageId=1114270

authors: gqcn x-controller

repo: gogf/gf


text:
upload failed with *ghttp.UploadFile

What version of Go and system type/arch are you using?

$ go version
go version go1.21.4 linux/amd64

What version of GoFrame are you using?

$ gf --version
v2.6.3
Welcome to GoFrame!
Env Detail:
  Go Version: go1.21.4 linux/amd64
  GF Version(go.mod):
    github.com/gogf/gf/v2@v2.6.3
CLI Detail:
  Installed At: /home/lee/.bin/gf
  Built Go Version: go1.20.8
  Built GF Version: v2.6.3
  Git Commit: 2024-02-07 17:11:36 d64a31fd1aa490ff9136c1776806f197d86c38a6
  Built Time: 2024-02-07 17:13:07
Others Detail:
  Docs: https://goframe.org
  Now : 2024-02-11T10:08:10+08:00

Can this bug be re-produced with the latest release?
Yes
What did you do?

以下是我的重现步骤，脚本可以另存为后直接运行
#!/usr/bin/env bash
# leehom Chen clh021@gmail.com

# 初始化项目
rm -rf demo
gf init demo # -u

cd demo || exit
git init

# 添加 upload 接口
(
echo 'package v1'
echo ''
echo 'import ('
echo '	"github.com/gogf/gf/net/ghttp"'
echo '	"github.com/gogf/gf/v2/frame/g"'
echo ')'
echo ''
echo 'type FileUploadReq struct {'
echo '	g.Meta `path:"/file/upload" method:"post" mime:"multipart/form-data" tags:"文件" summary:"上传文件"`'
echo '	File   ghttp.UploadFile `json:"file" type:"file" dc:"选择上传文件"`'
echo '}'
echo ''
echo 'type FileUploadRes struct {'
echo '	Id   int64 `json:"id"  dc:"文件ID"`'
echo '	Name string `json:"name" dc:"文件名称"`'
echo '	Url  string `json:"url"  dc:"访问URL，可能只是URI"`'
echo '}'
) > api/hello/v1/file.go

# 添加 control
make ctrl
(
echo 'package hello'
echo ''
echo 'import ('
echo '	"context"'
echo ''
echo '	v1 "demo/api/hello/v1"'
echo '	"demo/internal/service"'
echo ')'
echo ''
echo 'func (c *ControllerV1) FileUpload(ctx context.Context, req *v1.FileUploadReq) (res *v1.FileUploadRes, err error) {'
echo '	res, err = service.File().FileUpload(ctx, req)'
echo '	return'
echo '}'
) > internal/controller/hello/hello_v1_file_upload.go

# 添加 logic
mkdir -p internal/logic/file/
(
echo 'package file'
echo ''
echo 'import ('
echo '	"context"'
echo '	v1 "demo/api/hello/v1"'
echo '	"demo/internal/service"'
echo ''
echo '	"github.com/gogf/gf/os/gfile"'
echo '	"github.com/gogf/gf/os/gtime"'
echo '	"github.com/gogf/gf/v2/frame/g"'
echo ')'
echo ''
echo 'type sFile struct {'
echo '}'
echo ''
echo 'func init() {'
echo '	service.RegisterFile(New())'
echo '}'
echo ''
echo 'func New() *sFile {'
echo '	return &sFile{}'
echo '}'
echo ''
echo 'func (s *sFile) FileUpload(ctx context.Context, in *v1.FileUploadReq) (out *v1.FileUploadRes, e error) {'
echo '	uploadPath := "./uploads/"'
echo '	dateDirName := gtime.Now().Format("Ymd/His")'
echo '	g.Dump(in.Meta)'
echo '	g.Dump(in.File)'
echo '	fileName, e := in.File.Save(gfile.Join(uploadPath, dateDirName), true)'
echo '	if e != nil {'
echo '		return nil, e'
echo '	}'
echo '	out = &v1.FileUploadRes{'
echo '		Name: fileName,'
echo '		Url:  "/upload/"+dateDirName+"/"+fileName,'
echo '	}'
echo '	return'
echo '}'
) > internal/logic/file/file.go

# 添加 service
make service

# API 测试界面
(
echo ''
echo 'const ('
echo '	swaggerUIPageContent = `'
echo '<!DOCTYPE html>'
echo ''
echo ''
echo '  <meta charset="utf-8" />'
echo '  <meta name="viewport" content="width=device-width, initial-scale=1" />'
echo '  <meta name="description" content="SwaggerUI"/>'
echo '  <title>SwaggerUI</title>'
echo '  <link rel="stylesheet" href="https://unpkg.com/swagger-ui-dist@latest/swagger-ui.css" />'
echo ''
echo ''
echo '

'
echo ''
echo ''
echo ''
echo ''
echo '`'
echo ')'
) >> internal/cmd/cmd.go
sed -i '22i\
				group.GET("/apidoc", func(r *ghttp.Request) {r.Response.Write(swaggerUIPageContent)})' internal/cmd/cmd.go

# 运行项目
go get -u # 升级 goframe, v2.5.* 的api文档不能正确显示 fileupload
go mod tidy
# gf run ./main.go

执行上述脚本后，访问: http:localhost:8000/apidoc
尝试 file/upload 接口，上传任意文件，均出现 500 错误，空指针。
What did you expect to see?
I want to see the file uploaded successfully and see the uploaded file in the corresponding uploads/YYYYMMDD/HHIISS/ directory.
我希望看到文件上传成功，在 uploads 目录下发现新文件。
What did you see instead?
$ gf run ./main.go
build: ./main.go
go build -o ./main  ./main.go
./main
build running pid: 43847
2024-02-11 10:05:56.286 [INFO] pid[43847]: http server started listening on [:8000]
2024-02-11 10:05:56.286 [INFO] {eee58a91c1acb217da124106e7da9ba0} swagger ui is serving at address: http://127.0.0.1:8000/swagger/
2024-02-11 10:05:56.286 [INFO] {eee58a91c1acb217da124106e7da9ba0} openapi specification is serving at address: http://127.0.0.1:8000/api.json

  ADDRESS | METHOD |    ROUTE     |                          HANDLER                          |           MIDDLEWARE
----------|--------|--------------|-----------------------------------------------------------|----------------------------------
  :8000   | ALL    | /api.json    | github.com/gogf/gf/v2/net/ghttp.(*Server).openapiSpec     |
----------|--------|--------------|-----------------------------------------------------------|----------------------------------
  :8000   | GET    | /apidoc      | demo/internal/cmd.glob..func1.1.1                         | ghttp.MiddlewareHandlerResponse
----------|--------|--------------|-----------------------------------------------------------|----------------------------------
  :8000   | POST   | /file/upload | demo/internal/controller/hello.(*ControllerV1).FileUpload | ghttp.MiddlewareHandlerResponse
----------|--------|--------------|-----------------------------------------------------------|----------------------------------
  :8000   | GET    | /hello       | demo/internal/controller/hello.(*ControllerV1).Hello      | ghttp.MiddlewareHandlerResponse
----------|--------|--------------|-----------------------------------------------------------|----------------------------------
  :8000   | ALL    | /swagger/*   | github.com/gogf/gf/v2/net/ghttp.(*Server).swaggerUI       | HOOK_BEFORE_SERVE
----------|--------|--------------|-----------------------------------------------------------|----------------------------------

{}
{
    Filename:  "",
    Header:    {},
    Size:      0,
    content:   [],
    tmpfile:   "",
    tmpoff:    0,
    tmpshared: false,
    ctx:       <nil>,
}
2024-02-11 10:06:12.148 {cf34454ec5acb21751aeab176b715246} 500 "POST http 127.0.0.1:8000 /file/upload HTTP/1.1" 0.000, 127.0.0.1, "http://127.0.0.1:8000/apidoc", "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36", 68, "Internal Panic", ""
Stack:
1. exception recovered
   1).  github.com/gogf/gf/net/ghttp.(*UploadFile).Save
        /home/lee/.cache/.go-global/1.21.4/pkg/mod/github.com/gogf/gf@v1.16.9/net/ghttp/ghttp_request_param_file.go:52
   2).  demo/internal/logic/file.(*sFile).FileUpload
        /home/lee/Projects/tmp_upload/demo/internal/logic/file/file.go:34
   3).  demo/internal/controller/hello.(*ControllerV1).FileUpload
        /home/lee/Projects/tmp_upload/demo/internal/controller/hello/hello_v1_file_upload.go:11
2. runtime error: invalid memory address or nil pointer dereference

没有复现，用你脚本生成的。gf版本github.com/gogf/gf/v2@v2.6.3
$ gf -v
v2.7.1
Welcome to GoFrame!
Env Detail:
  Go Version: go1.20.12 windows/amd64
  GF Version(go.mod):
    github.com/gogf/gf/v2@v2.6.3
CLI Detail:
  Installed At: C:\hailaz\go\bin\gf.exe
  Built Go Version: go1.20.12
  Built GF Version: v2.7.1
Others Detail:
  Docs: https://goframe.org
  Now : 2024-05-24T17:57:24+08:00

如果还有问题，就重新打开这个issue。


text:
container的garray.StrArray的join方法能否设置一个参数表示是否不用转义检测

建议container的garray.StrArray的join方法能否设置一个参数表示是否不用转义检测
1. What version of Go and system type/arch are you using?
golang 1.13 linux/amd64
2. What version of GoFrame are you using?
gf version 1.9.7
3. Can this issue be reproduced with the latest release?
最近更新gf版本后，原本正常的业务出现异常，在排查后发现是因为新gf的strarray的join方法修改了导致join出来的字符串和原来行为不一致，字符串中添加了“，导致拼接的字符串进入业务逻辑后出现异常，测试代码如下，以前的版本是没有添加多余的“，查看了gf版本变更记录后发现，改方法的逻辑修改了，能否添加一个标志，来确认是否修改字符串拼接逻辑

@foxhack 问题收到。

@foxhack 已修复，请更新到最新框架代码再试试。

authors: foxhack johngcn


text:
Regression: error calling Paginator: pagination not supported for this page: kind: "page"

Up until Hugo 0.122, you could (in a partial) check if the current page is paginated like this:
{{- if .Page.Paginator -}}

Since Hugo 0.123 this is no longer possible. Instead you get this error:

error calling Paginator: pagination not supported for this page: kind: "page"

I reckon that this could be an intended change, although it's not listed in the list of breaking changes (#11455) and so I thought to better report it.
The change could be related to #11949 but I never experienced this bug (it simply worked for me).
What version of Hugo are you using (hugo version)?

$ hugo version
hugo v0.123.0-3c8a4713908e48e6523f058ca126710397aa4ed5+extended windows/amd64 BuildDate=2024-02-19T16:32:38Z VendorInfo=gohugoio

Does this issue reproduce with the latest release?
Yes

This was a bug fix.
You can do something ala:
{{- if and .Page.IsNode .Page.Paginator -}}

Be careful when using .IsNode as suggested above; it returns true in the 404 template. See https://github.com/gohugoio/hugo/issues/12162 and https://github.com/gohugoio/hugo/issues/12192.

This is interesting. It's still there when I updated to 0.124.1.
Thanks for the .IsNode check. That works fine.

Be careful when using .IsNode as suggested above; it returns true in the 404 template. See #12162 and #12192.

So are there any other better solutions?

authors: bep jmooring shinyzhu skrysmanski

repo: gohugoio/hugo


text:
Ability to disable section list page routes but have valid routes for pages in that section

I have this folder structure:
/contents
↳ /docs
   ↳ /core concepts
      ↳ _index.md
      ↳ load.md
     ↳ routing.md
   ↳ /getting started
     ↳  _index.md
     ↳  introduction.md
     ↳  project-structure.md
Objective
I want these page routes to list the appropriate page (which it is doing correctly):
/docs/core-concepts/load    (page)
/docs/core-concepts/routing (page)
/docs/getting-started/introduction    (page)
/docs/getting-started/project-structure (page)

I want a 404 returned for these routes instead of currently display the list page for the section
/docs/core-concepts/ (section list)
/docs/getting-started/ (section list)

I followed the instructions below from : https://gohugo.io/content-management/build-options/#example----publish-without-listing
+++
title = 'Core Concepts'
[build]
  list = 'never'
  render = 'never'
+++

/docs/core concepts/_index.md
/docs/getting started/_index.md
Problem
It blocks out the entire route tree. Neither the pages or lists get produced.

@bep Are you saying that it's currently not possible?

I am unable to reproduce the problem as described. Try it:
git clone --single-branch -b hugo-github-issue-13185 https://github.com/jmooring/hugo-testing hugo-github-issue-13185
cd hugo-github-issue-13185
rm -rf public/ && hugo && tree public

There does seem to be a bug including in your project:
If you were to run this snippet from within a Page that is in the Core Concepts or Getting Started section:
{{ range site.AllPages }}
        {{ .Section }}. <------- Always prints docs.
{{ end }}

{{ range site.Sections }}
        {{ $section := . }}
        {{ if eq $section.Section "docs" }}
          Arrived Here
          {{ range $section.Pages }}
            {{ . }} <------ Empty
          {{ end }}
        {{ end }}
      {{ end }}

I don't seem to be able to find the section name "Core Concepts" or "Getting Started".
I don't seem to be able iterate over the Pages of those Sections either.
It's as if the section's list pages are not rendered (That's what I want), but those sections don't even exist, including for the Pages that are inside those sections!

Always prints docs.

No matter where you are in the tree under the content/docs directory, the Section method should return docs (a string). See https://gohugo.io/methods/page/section/.

I don't seem to be able to find the section name "Core Concepts" or "Getting Started"

You also said:

I want a 404 returned for these routes

If you want to list the members of a specific section, even when the section's list and render build options are never, use the Page.GetPage method and then range over its children. See https://gohugo.io/methods/page/getpage/.
{{ range (.GetPage "/docs/core-concepts").Pages }}

{{ .LinkTitle }}

{{ end }}

See: https://discourse.gohugo.io/t/ability-to-get-section-names-programmaticall/52872

authors: jmooring pjebs


text:
Multiple config files and menu entries

So, after 0.27 was out, I quickly switched to splitting my configs to reduce duplication.
It worked great except for one thing: menus.
I had this in config-common.yml:
menu:
    main:
        - Name: "A"
          URL: "https://foo.bar/"
          Weight: -10

And then I had this in config-development.yml
menu:
    main:
        - Name: "B"
          URL: "https://foo.bar/diff/"
          Weight: 0

When I run Hugo with --config=config-common.yml,config-development.yml only the "B" menu is showing up; it's like it overwrites config-common.yml's menu entry.
The other menu entries are defined in each page's front matter and are common and they do show up fine.

Did you expect us to deeply merge those config maps? I'm pretty sure that is not supported.

I thought it was a limitation too, but at first I expected those to be merged.
Deep merging would extend this feature even further. Not sure how much slower it would be though.

Thinking about it, I believe deep merging of maps is actually supported, but your case works as expected in my head.

The menu key is main with a list of entries
Your second config replaces that main with another list of entries

We have no way of knowing which menu entry to keep/throw away.

OK, then I might be missing something.
Is there any other way to define the menu URL in the config file without overwriting the key? That way I could just change the URL.

Now you're deep into the questions that belong on the forum.

what about being able to override one of the items in the menu, like URL, so same name and id.
_default/config.toml
[[menu.home]]
    identifier   = "docs"
    name = "Docs"
    url = "/docs"
    weight = 1

[[menu.home]]
    identifier   = "signin"
    name = "Sign In"
    url = "https://example.dev"
    weight = 1

production/config.toml
[[menu.home]]
    identifier   = "signin"
    name = "Sign In"
    url = "https://example.com"
    weight = 1

in production, the docs menu does not show up.

authors: XhmikosR bep ramarnat


text:
Add multilingual multihost support

The current multilingual support in Hugo is restricted to 1 baseURL, i.e. the languages are put into subfolders named after the language code (the default language may be kept on the top level), i.e. https://example.com/en etc.
This works great and is possibly the most common use case.
This does, however, not allow using the baseURL to differentiate the languages, i.e. https://en.example.com, https://jp.example.com and similar variations.
Core Changes
This issue describes a way to define a baseURL per language. The new rule will be:

If a baseURL is set on the language level, then all languages must have one and they must all be different.

Example:
[languages]
[languages.no]
baseURL = "https://example.no"
languageName = "Norsk"
weight = 1
title = "På norsk"

[languages.en]
baseURL = "https://example.com"
languageName = "English"
weight = 2
title = "In English"

With the above, the two sites will be generated into public with their own root:
public
├── en
└── no

The important part here is that:
All URLs (i.e .Permalink etc.) will be generated from that root. So the English home page above will have its .Permalink set to https://example.com/.
Hugo Server
The changes above will work for the regular hugo; the two sites will be ready to be configured as two virtual hosts in Nginx or similar.
But you'd want to test it before you go live, of course. So we need to adapt hugo server to also handle multiple base URLs.
This issue suggests that we start as many HTTP servers as there are languages. Which, in its default port settings will just increment from port 1313 and get:
http://localhost:1313/
http://localhost:1314/
...

Then you can navigate the sites (i.e. jump from article to its translations etc.) just as it was deployed live on your production environment.
Multiple content and static dirs
Also see #4073 and #3757
With the new deployment topology this new feature creates, you often end up wanting better control of your content and your static files.
We will improve on this on two levels:

staticDir and contentDir can now be a slice of strings.
Each language can have its own staticDir and contentDir setting.

All the static directories will create a union filesystem from left to right:
theme static dir, global config static dirs, language static dirs.
The content dirs will behave similarly (but no theme dir).
Example:
staticDir = ["static1", "static2"]
[languages]
[languages.no]
staticDir = "static_no"
baseURL = "https://example.no"
languageName = "Norsk"
weight = 1
title = "På norsk"

[languages.en]
staticDir = "static_en"
baseURL = "https://example.com"
languageName = "English"
weight = 2
title = "In English"

In the above, no theme used, the English site will get its static files as a union of "static1", "static2" and "static_en". On file duplicates, the right-most version will win.
/cc @RickCogley

Thank you for organizing this @bep.
An aside: the .co.jp domain is an interesting one, because the authorities in Japan regulate it so that one corporate entity in Japan can get only one .co.jp domain. (There was a big problem at the beginning of the Internet here, with people "squatting" on .co.jp domains.) Sometimes after a Japan entity gets a .co.jp, they put other languages under say .com or .no etc, whatever is logical for that language.
I can think of these things:

the idea that it will start many HTTP servers with a different port per language is great. Hugo server would need to increment up from a CLI-specified port, given multiple baseURLs, as well.
Japanese registrars offer kanji domain names now (technically, IDN's), like 日本語.jp etc. It might be an edge case, but does hugo allow a baseURL that is non-ASCII? Reference: https://unicode.org/faq/idn.html

but does hugo allow a baseURL that is non-ASCII?

Yes, Hugo is all UTF-8 and I'm pretty sure what we do no "normalization" of the baseURL part.
As to hugo server there are some existing logic that says that we use localhost by default if --baseURL is not set in CLI. We probably need something like this here as well. You would normally not use a "real domain" in test, but I use some TypeKit fonts in my sites, so I need a local domain (defined in my hosts file) to get the validation to pass. But let me think about that when I get to it.

thanks @bep. I didn't say that first point well. I meant to say, if the port is set on the CLI, then hugo would need to increment up from that.
Regarding typekit needing a local domain, I did not know that, and just specified "localhost" and "127.0.0.1" in the typekit "kit editor" setup, for my sites that use typekit. It seems to work...

just specified "localhost" and "127.0.0.1" in the typekit "kit editor" setup, for my sites that use typekit. It seems to work...

Yes, that works too, I guess, but having a "secret domain" prevents others from using my subscription. Not a big thing.
And yes; I agree about the incremental port thing.

ah, never thought of that. Uh oh!

Just to complete that thought. I have something like this in /etc/hosts:
127.0.0.1   somename.local

And then I do hugo server --baseUrl=http://somename.local.
Which I will make sure works also in a multihost setup (http://somename.local:1313, http://somename.local:1314 etc.).

@RickCogley I'm back from Spain and about to wrap my head around finishing this implementation.
One remark:
We may refine this in the future, but my first take on the static folder will be to duplicate it for the different languages. Which I think makes the most sense.

Welcome back @bep. Hope you got to relax & enjoy. :-)
Yeah, I can see duplicating static. Just wondering, if I had stuff that was shared between both sites, could I use a symlink between? Say, the main language's static/img is linked into other languages' static/img. Or, doesn't hugo deal well with symlinks...?

@RickCogley I have a better idea. I will revise my first post to include this.

@RickCogley I have updated the description with a new section about this. I think this will be very valuable, not just for this particular feature.

@bep, the current description lists this config block (with irrelevant elements removed):
[languages]
staticDir = "static_no"
[languages.no]

[languages.en]
staticDir = "static_en"

Did you mean to include staticDir = "static_no" directly under the [languages] table?

Did you mean to include staticDir = "static_no" directly under the [languages] table?

Copy and paste mistake. Thanks for spotting.

@bep that sounds slick. Given the same file in say static_en/img and static_ja/img which one will "win" if the idea is the "right most" will? Will it be alphabetical, or, last defined in the config.toml?
Also, are the rules different if, say, they have the same filename but one is newer?

I have updated the description with a new section about this. I think this will be very valuable, not just for this particular feature.

On file duplicates, the right-most version will win.

Given the same file in say static_en/img and static_ja/img which one will "win" if the idea is the "right most" will?

In my head: In the above case, no files in static_ja/img will be visible in the English site and vice versa. That is the foundation of this. So you can have logo.png in both places and it would just work. I don't think it would make sense to mix those two "bags of resources". This becomes even more clear when we start to talk about content.
The "righ most" is for the Japanese site the static_jp/img, for English static_en/img -- with a note to the above: Files from static_jp/img will not be visible to the English site.

Also, are the rules different if, say, they have the same filename but one is new

No.

@RickCogley considering #2699 it may (at least for the content part) make sense to let both "language folders" be visible to both -- but in the static case the current language will always win on duplicates. Will think.

@bep If you set:
 staticDir = ["static1", "static2"]

... do you also have to add the language static dirs like static_no into that?
 staticDir = ["static1", "static2", "static_no"]

Or are those set under the language blocks only?
In a multilingual site, in my experience you have images that are language specific but, you also have images that are common to both. So I suppose, common ones go into "global static" and language specific go into "language specific" correct?

Or are those set under the language blocks only?

Yes.

So I suppose, common ones go into "global static" and language specific go into "language specific" correct?

Yes. The use case for having a "static_no" is typically for assets that are different between the two languages: Logo (text in the particular language), maybe also CSS files per language, whatever.

Ok, it seems clean / good to me.
Someone will probably stick their language statics in there, though! :-)

I need some help with a name. The cleanest way of doing this is to let staticDir on language level override the global (which then behaves like everything else) and create one more setting for additional directories for that language.
[languages.en]
staticDir = "mystatic"
staticOtherDir = "static_en"
baseURL = "https://example.com"

So the staticOtherDir will be the "extra" dir for that language. But I need a better name for it?

How about staticLangDir ?
On Mon, Nov 13, 2017 at 3:24 AM, Bjørn Erik Pedersen <
notifications@github.com> wrote:

I need some help with a name. The cleanest way of doing this is to let
staticDir on language level override the global (which then behaves like
everything else) and create one more setting for additional directories
for that language.
[languages.en]
staticDir = "mystatic"
staticOtherDir = "static_en"
baseURL = "https://example.com"
So the staticOtherDir will be the "extra" dir for that language. But I
need a better name for it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gohugoio/hugo/issues/4027#issuecomment-343756526, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAfRSPV18vajr8YtP7rJ7jqqpHWSG1_Bks5s1zfcgaJpZM4QLjoO
.

--
Rick Cogley
rick.cogley@esolia.co.jp | M: 090-9959-5452

Bilingual IT solutions and management firm—eSolia*

--
This email message and any attachments are confidential, and are meant to
be read by the intended recipient only. If you are not the intended
recipient, we would request you delete this message or any attachments
without reading or distributing, and kindly advise eSolia Inc. (contacts:
esolia.com/about http://esolia.com/about). Thank you in advance.

How about staticLangDir?

I have slept on this, and I think I have figured out a good way to differentiate override these static dirs vs add these static dirs.
It will behave conceptually a little different when running in multihost mode vs regular, but I think it should be logical for most people.
If you need more staticDir properties, add an ID as suffix. An ID is a integer between 1 and 10.
So:
staticDir = ["static1", "static2"]
[languages]
[languages.no]
staticDir = ["static1"]
staticDir2 = "static_no"
baseURL = "https://example.no"
languageName = "Norsk"
weight = 1
title = "På norsk"

[languages.en]
staticDir2 = "static_en"
baseURL = "https://example.com"
languageName = "English"
weight = 2
title = "In English"

The above shows a mix of override and additions.
For no: "static1", "static_no"
For en: "static1", "static2", "static_en"
In both of the above, the right-most directory will win on duplicates.

Oh, smart!

Override a global staticDir property by specifying the same property name as the global, under the language.
Give a language a unique static directory by specifying a unique property name under the language block.

@bep Is it possible to add custom Google Analytics ID for each language domain? And if not, when it can be implemented?

@biodranik you can set site params per language

authors: Hanzei RickCogley bep biodranik moorereason


text:
Heading render hooks to allow better fixing of header overlaps in themes

The Issue
Many websites include non-scrolling headers that are fixed to the top and have a defined height. When clicking on a URL anchor (#fragment) browsers do not respect the height of the fixed header resulting in users being taken too far down the page.
Background
A quick and dirty fix would be to nest a span inside all heading elements like so:

one

and then the HUGO theme's styling could make adjustments as needed:
h3{ position:relative; }
h3 span{ position:absolute; top:-120px;}

The issue with this approach is that it could break a lot of existing HUGO themes out there.
Proposal
Add a render hook template for headings that would allow theme developers to modify headings, such as in the "dirty" example above, as needed by the theme.
For example, /layouts/_default/_markup/render-h1.html, could be written as:

{{ .Content }}

For anyone who stumbles across this feature request here's a SCSS workaround. It works but definitely causes a browser performance hit. I recommend further-narrowing the selector scope as much as you can.
  h1,
  h2,
  h3,
  h4,
  h5,
  h6 {
    &[id]::before {
      /* Header height offset for anchor links */
      content: "";
      display: block;
      height: var(--menu-height);
      margin-top: calc(var(--menu-height) * -1);
      visibility: hidden;
    }
  }

I thought long and hard before we added the render hooks for images and links. For those use cases it makes a lot of sense, but that is because in most situations you need to add some logic and hook into Hugo's API to resolve links, resize images etc.
Your problem does not require any Hugo  "hooks" and would be much simpler to implement, and would benefit more people if it was added behind some flag in Goldmark's HTML renderer.
I suggest you raise an issue there and link back to this issue.

@bep Thanks for your work on this project!  I have opened an upstream feature request on the goldmark project as you have suggested: https://github.com/yuin/goldmark/issues/86

authors: bep dudleycodes


text:
octocat emoji is not working in markdown.

What version of Hugo are you using (hugo version)?

$ hugo version

Hugo Static Site Generator v0.62.2/extended windows/amd64 BuildDate: unknown

Does this issue reproduce with the latest release?

What exactly do you mean by this?

In the content page, the octocat emoji is not converting. If I am writing a post in .md and writing  :octocat: it is displaying as it is in html :octocat: instead of this :octocat: .

But aren't the :emoji: specific to GitHub (and not Hugo)?

:D octocat is github-only. It's not an emoji. It's a replacement in Github markup.

Okay, understood. I thought markdown supports it. Thanks for the clarification.

authors: VilhelmPrytz bep davidsneighbour schadokar


text:
Add universal widget state

Things like hovered, focused, selected, enabled, and disabled should be universal properties that can be used for styling.

Also, all of those should be signals as well.

Actually, it might make more sense to build on the already existing flags.

done in new v2

authors: kkoreilly rcoreilly

repo: goki/gi


text:
fix output name

I've not sure what the original goal of the [name] addition was, but it doesn't match your end result and fails when you use the webpack-dev-server :)

@gnesher You are right. I meant hash.bunlde.js instead of name.bundle.js. Its a mistake. Thanks for the PR 👍

authors: gnesher gokulkrishh


text:
error while parsing Gopkg.lock: Unable to parse the lock as TOML: (76, 11): unescaped control character U+000A

What version of dep are you using (dep version)?
dep:
 version     : v0.4.1
 build date  : 2018-01-24
 git hash    : 37d9ea0a
 go version  : go1.9.1
 go compiler : gc
 platform    : windows/amd64

Go env:
C:\Users\luo>go env
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\luo\AppData\Local\go-build
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\GoPath
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\luo\AppData\Local\Temp\go-build748123634=/tmp/go-build -gno-record-gcc-switches

OS:
Microsoft Windows 10 Pro x64
10.0.17134 Build 17134

What dep command did you run?
go get github.com/solo-io/unik
cd unik
dep init
dep ensure

What did you expect to see?
The dependency should be synced based on Gopkg.toml and Gopkg.lock generated by dep init
What did you see instead?
C:\GoPath\src\github.com\solo-io\unik>dep ensure
error while parsing C:\GoPath\src\github.com\solo-io\unik\Gopkg.lock: Unable to parse the lock as TOML: (76, 11): unescaped control character U+000A

I made some progress.
My project uses godep and I want to migrate it to official dep. The original godep is: https://github.com/solo-io/unik/blob/master/Godeps/Godeps.json. It turns out that when migrating from godep to dep, dep init generates the Gopkg.lock file with mistakes.
Here's a fragment of the Gopkg.lock file. You can see that "github.com/gin-gonic/gin" is mistaken as "github.com/gin-gonic/g. The actual translation result lacks the last two letters in and the closing quote mark ". I don't know why dep init causes such a strange mistake?
[[projects]]
  name = "github.com/Sirupsen/logrus"
  packages = ["."]
  revision = "3ec0642a7fb6488f65b06f9040adc67e3990296a"

[[projects]]
  name = "github.com/gin-gonic/g  # <------ here should be "github.com/gin-gonic/gin"
  packages = [
    ".",
    "binding",
    "render"
  ]
  revision = "542be2fe77724f800fcab7eb6c01a4e597fb8506"

Since the question has changed, I think I should present the question in a new issue: https://github.com/golang/dep/issues/1906. Closed here.

repo: golang/dep

license_source: bigquery


text:
go get --verbose

It is unclear what go is doing while trying to get LXD for development with go get github.com/lxc/lxd. It hangs for a lot of time and I don't know if it is network problem or just long checkout:
$ go version
go version go1.4.2 linux/amd64

What I expect at first is some command line help:
$ go get github.com/lxc/lxd -h
package -h: unrecognized import path "-h"
$ go get github.com/lxc/lxd --help
package --help: unrecognized import path "--help"

And then:
$ go get github.com/lxc/lxd --verbose
downloading ....
compiling ...
etc ...

Flags go before arguments.
dominikh-pc ~ $ go get -h github.com/lxc/lxd
usage: get [-d] [-f] [-fix] [-t] [-u] [build flags] [packages]
[...]

(and of course, with -h it makes no sense to specify a package path).
Verbose also exists: -v

@dominikh it is a convenience feature. Editing a line to insert --help before package name when you need to lookup something you've forgot is a nuisance after Python where optparse handles this gracefully.
Well, cool that -v exists, but you see that I was unable to use it, because well I used to add options at the end.

$ go get --help
usage: get [-d] [-f] [-fix] [-insecure] [-t] [-u] [build flags] [packages]

Shouldn't it list -v there?

This bug is closed. We don't re-use old bugs.

authors: bradfitz dominikh epitron techtonik

repo: golang/go


text:
Permission denied on osx, with "go install" command when I set GOOS=linux

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go1.8.3
What operating system and processor architecture are you using (go env)?
darwin/amd64
What did you do?
export GOOS=linux
go install
The error message is:
go install runtime/internal/sys: mkdir /usr/local/go/pkg/linux_amd64: permission denied
I also have this issue. On OSX, go1.8.3 darwin/amd64. If I set GOOS=linux, then it fails, because it want to create the pkg directory on GOROOT and not on GOPATH.
This is the error message:
go install runtime/internal/sys: mkdir /usr/local/go/pkg/linux_amd64: permission denied
GOPATH is "/Users/xxx/Documents/GitHub/developments/go/"

If I set back GOOS to darwin with export GOOS=darwin command, then it works again, it uses the GOPATH variable as deployment destination, again.

See the section on "go build vs go install" in the blog post.  https://dave.cheney.net/2015/08/22/cross-compilation-with-go-1-5

On 4 Jun 2017, at 17:18, Gergely Szécsényi notifications@github.com wrote:
If I set back GOOS to darwin with export GOOS=darwin command, then it works again, it uses the GOPATH variable as deployment destination, again.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I'm seeing this same issue but with exporting GOOS=windows on Linux and running go get, which in turn calls go install.  I have GOPATH set to a local directory but go install appears to be ignoring it.  My workaround is to just run go get before changing GOOS in my build scripts.
Probably obvious but my CI job is building Windows and Linux binaries on a Linux build machine.

@matthewcummings can you please open a new issue including all the required information in the template. Please also include the output of adding the -x flag to go get/install which will show us the commands the Go tool executed.
If this turns out to be a duplicate then we’ll merge the issues. Thanks.

@gszecsenyi - Please use go build instead of go install when cross-compiling. The reasons are clearly laid out in Dave's blog post. I suggest closing this issue.

Using go build vs go install
When cross compiling, you should use go build, not go install. This is the one of the few cases where go build is preferable to go install.

The reason for this is go install always caches compiled packages, .a files, into the pkg/ directory that matches the root of the source code.

For example, if you are building $GOPATH/src/github.com/lib/pq, then the compiled package will be installed into $GOPATH/pkg/$GOOS_$GOARCH/github.com/lib/pq.a.

This logic also holds true for the standard library, which lives in /usr/local/go/src, so will be compiled to /usr/local/go/pkg/$GOOS_$GOARCH. This is a problem, because when cross compiling the go tool needs to rebuild the standard library for your target, but the binary distribution expects that /usr/local/go is not writeable.

Using go build rather that go install is the solution here, because go build builds, then throws away most of the result (rather than caching it for later), leaving you with the final binary in the current directory, which is most likely writeable by you.

Closing for now given this (very good) explanation from @davecheney’s post.

authors: agnivade andybons davecheney gszecsenyi matthewcummings