text:
Custom features are not working with OS.has_feature or "Override for"

Godot version:
GODOT 3.2.1 - released March 10, 2020
OS/device including version:
Windows 10 Home x64
Issue description:
When trying to export two different build, one for the client and one for the server, the custom features are not working.
If I create a new export template with a custom feature server_build, neither the Override for nor the OS.has_feature seem to be working.
I already saw this issue for the override and this other one for the OS access, but I can't get it working. I just downloaded the latest version of the engine with no success.
Steps to reproduce:

Export the repo with the default features

Should show a main screen with a label "Client Build" and printing in the console "The client build"

Export the repo with a custom feature server_build

EXPECTED Should show a main screen with a label "Server Build" and printing in the console "The server build"
RESULT The same main screen and console output are shown, as if the build was made without the custom feature

Minimal reproduction project:
custom_feature_bug.zip

Okay, that was a bug that I've been facing since the beginning of my project around 2 months ago. I couldn't think of any workarounds or fixes up until now.
Hopefully it gets properly fixed soon - commeting the if/else to get server/client version of my project for n'th time was driving me insane and today I figured out this temp solution.
Instead of using custom feature to differentiate between server and client - do it through executable name:
func check_if_server() -> bool:     return OS.get_executable_path().ends_with("Server.exe")
Hope it serves you well for the time being. Cheers!

Thanks @Luzkan I'll give it a try!

Any word on a fix? This is a bad blocker for me as Im trying to create a client and server in one project. Can't build either without modifying code between exports

@systemsoverload As a workaround, you could use environment variables, check for the presence of a file, check the executable name, and more.

Another idea: let your build script change constant variables in your .gd file between Exports. Maybe you got a auto-loaded Constants.Is_server=true, you can automatically change to false before exporting a client.
I'm using a python script to build, deploy and publish my game, and I do this kind of thing to set a version number that both server and client can read and check for. As far as I know, such a game version attribute is badly missing in godot too.

@mrimvo There's a pull request that implements a version project setting: https://github.com/godotengine/godot/pull/35555

This is another bug actually, see #42978
Everything will work when you move the executable outside your project directory.

authors: Calinou KoBeWi Luzkan eastolfi mrimvo systemsoverload


text:
Incorrect saving of files.

Operating system or device: Windows 8 / ArchLinux
Issue description:
In assembled form, the draft can't save variables to a file. Or doesn't record, or not creates a file. In the editor everything works fine.
Steps to reproduce:

export demo "read_write" (simple demo)
Running with console

Link to minimal example project (optional but very welcome):
https://www.dropbox.com/sh/4tut8st36k8oejn/AACaOj5sAZPHqJfnVR9SIyu9a?dl=0

Please answer the above question, as for now there's nothing we can do on this issue, it's hard to understand what the problem was/is.

I think he means that he can't save files to res:// paths, which is intended. Use the user:// path to save files when exporting

source: gharchive/issue

authors: Timofffee akien-mga reduz

repo: godotengine/godot

license: MIT

license_type: permissive

license_source: github-api


text:
editor/script_editor_debugger.cpp:261 - Condition "!breaked" is true.

Godot version:
3.2.1
Issue description:
mash instances spawn black instead of white. Colour change is not possible.

@Talunava Please upload a minimal reproduction project to make this easier to troubleshoot. Also, please give some steps to reproduce this bug.

No reply from OP. Without any information, we can't do anything.
We can reopen if we get any further information. :)

authors: Calinou Talunava clayjohn


text:
error getting the modified time of a file while running the editor

Not critical, but im getting this in the console
ERROR IN: res://assets/bionickid.fnt::0
ERROR: _get_modified_time: Method/Function Failed, returning: 0
At: drivers/unix/file_access_unix.cpp:233.
The resource is there:
$ stat assets/bionickid.fnt
File: ‘assets/bionickid.fnt’
Size: 21365     	Blocks: 48         IO Block: 4096   regular file
Device: fe03h/65027d	Inode: 35512356    Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/voidplayer)   Gid: ( 1000/voidplayer)
Context: unconfined_u:object_r:user_home_t:SystemLow
Access: 2014-05-14 23:41:49.825771331 +0200
Modify: 2014-05-11 18:15:28.028585940 +0200
Change: 2014-05-11 18:15:28.028585940 +0200
Birth: -

Can you still reproduce the issue with a recent Godot build?

im not even sure what this was about. It was so long ago

authors: akien-mga voidplayer


text:
Input.get_joy_axis reporting at half precision steps

Godot version:
3.2.3.stable.official
OS/device including version:
Windows 10 Pro N 1903 18362.1139
Issue description:
Input.get_joy_axis method is only updating the value per 2 steps based on 0 to 255 range.
If you see the axis values in a software like XPadder, an axis is represented in 0 to 65535 range and you see the increments of 256, but Godot only updates in multiples of 512.

cc @madmiraal

I'm struggling to understand the issue. Input.get_joy_axis() returns a float between -1 and 1 not a discrete value in multiples of 512.
On Windows this value is extracted using the Windows API's XInputGetState function, which uses the XINPUT_GAMEPAD structure. As stated in the documentation, this returns values between 0 and 255 for triggers and -32768 and 32767 for the left and right, x- and y-axes i.e. a range of 65535. Godot stores these range values as constants:
https://github.com/godotengine/godot/blob/9dad483920ffa3c32a03f1f4cc869b3f7d1cbe0e/platform/windows/joypad_windows.h#L69
https://github.com/godotengine/godot/blob/9dad483920ffa3c32a03f1f4cc869b3f7d1cbe0e/platform/windows/joypad_windows.h#L66
It converts the values returned by the OS to a float by dividing the values by these constants:
https://github.com/godotengine/godot/blob/9dad483920ffa3c32a03f1f4cc869b3f7d1cbe0e/platform/windows/joypad_windows.cpp#L457-L473
At no stage does it use multiples of 512.

Let me try to explain myself, sorry if I'm not explaining it well enough by the way.
The issue I'm experiencing is that it seems that the method isn't reflecting the changes in the internal value (-32768 to 32767) when it changes in steps of 256.
For a device with 0-255 precision, 1 of its steps would be a change around 256, however the method doesn't reflect that in the value returned, it only updates when the device moves 2 steps from a correctly detected state.

An example just in case:
When sThumbLX is -256 the method should return -0.0078xx but it returns 0.
When sThumbLX is -512 the method should return -0.015625 and it returns -0.015625.
When sThumbLX is -768 the method should return -0.0234xx but it returns -0.015625.
When sThumbLX is -1024 the method should return -0.03125 and it returns -0.03125.
You get the idea, hah

@DJKero If what you're suggesting were true, then, when sThumbLX was at the negative limit i.e. -32768, the value Godot would return would be -0.5, but it doesn't, it returns -1; as using any joystick will show.
This leads me to believe that the values of sThumbLX are not what you assert, and that the problem lies with how you're setting the values for sThumbLX.

No, because:
-32768 / MAX_JOY_AXIS equals -1.0
The issue is in between the steps, you cannot test this with a common joystick.

Yeah you can reproduce this even with a cheapo steering wheel and some software that lets you see the value of the X axis like XPadder.

Something is not right with the values provided. I suspect the data from Xpadder may not be correct. Since neither Windows nor Xpadder provide their source code, I've looked at the Wine implementation. They use the following code to convert hardware joystick data to a short:
 327 static SHORT scale_short(LONG value, const struct axis_info *axis)
 328 {
 329     return ((((ULONGLONG)(value - axis->min)) * 0xffff) / axis->range) - 32768;
 330 }

Converting byte data to a short i.e. to get 0 to map to -32768 and 255 to map to 32767, results in the correct step size of 257, not 256, and there should be no 0 value:

Byte

Short

Float

126
maps to
-386
converts to
-0.0118

127
maps to
-129
converts to
-0.0039

128
maps to
128
converts to
0.0039

129
maps to
385
converts to
0.0117

Note: The 0.0039 value is the correct axis value you see in the Joypads Demo, when the joystick is at rest and the main reason why a dead zone is required:

Obviously, it's possible that hardware provides different axis->min and axis->range information, but I suspect most hardware is limited to providing byte data.
Note: It's not uncommon to get the conversion from bytes to shorts wrong as this Wine commit reveals from an earlier implementation.

I don't understand what that algorithm does, sorry.
I'll check with other software like XPadder to double check the values.

Here's proof there's something wrong:

Hi, I'm the creator of the arcin IO board that @DJKero is using and they asked me to help track down this issue.
The arcin is sending the axis values as an 8-bit number in the range 0..255.
I started out by attempting to reproduce the problem, doing (get_joy_axis() + 1) / 2 * 255 to scale the -1..1 range back to the original 0..255 range and found it to be moving in steps of three, but sometimes counting 0, 3, 6… and other times counting 1, 4, 7… and so on.
Going through the code, I found the following snippet in InputDefault::joy_axis():
	if (p_value.value > joy.last_axis[p_axis]) {

		if (p_value.value < joy.last_axis[p_axis] + joy.filter) {

			return;
		}
	} else if (p_value.value > joy.last_axis[p_axis] - joy.filter) {

		return;
	}

The value here is scaled to a 0..1 range, and joy.filter is hardcoded to 0.01. Since a single step is a little bit smaller than 0.004 in this scale, any update event with a smaller difference than three steps from the last reported value is dropped, which is consistent with the behavior I see. Changing joy.filter to 0 lets single steps through.
In other words, this is a feature, not a bug, presumably added to get rid of jitter from noisy joysticks. The problem is that it sacrifices precision and the filter threshold is as far as I can see hardcoded in the source, so it can't be changed by users needing the full precision.

I could try to help expose this through the API and learn in the process if you see fit.

The value here is scaled to a 0..1 range, and joy.filter is hardcoded to 0.01. Since a single step is a little bit smaller than 0.004 in this scale, any update event with a smaller difference than three steps from the last reported value is dropped, which is consistent with the behavior I see. Changing joy.filter to 0 lets single steps through.

@zyp Yes, I think that's it. Looks like the filter was added on the assumption that the input would be continuous and not in steps; so it's not needed.
BTW Depending on the axis, the value can also be scaled in the -1...1 range with steps of 0.008, but the principal is the same.

Thanks @madmiraal @zyp  @akien-mga 😁

authors: Calinou DJKero madmiraal zyp


text:
Internal Script Error - opcode 38

Godot version:
3.2.4 beta 1
OS/device including version:
KaOS Linux
Issue description:
I'm just reporting this cuz, the error says that, I think its related to declaring a variable inside a for loop which is the variable itself as can be seen below.
Steps to reproduce:

Duplicate of https://github.com/godotengine/godot/issues/43042 (will be fixed in 3.2.4beta2).

authors: Calinou nonunknown


text:
Can't use signal declared in abstract generic class

Godot version: 3.2.3.stable.mono

OS/device including version: Windows 19042.870, GTX1060 (Driver 461.09)

Issue description:

Working on a system I noticed I could give myself a nicer API by making the abstract base class generic over what entity or node it will be dealing with. There was one signal declared in the abstract base class which I was able to connect from concrete implementations of the base class before making the base class generic. With the generic type argument in use neither connecting nor emitting the signal works.
E 0:00:00.686   connect: In Object of type 'Node': Attempt to connect nonexistent signal 'MySignal' to method 'Node2D.MySignalCallback'.
  <C++ Error>   Condition "!signal_is_valid" is true. Returned: ERR_INVALID_PARAMETER
  <C++ Source>  core/object.cpp:1503 @ connect()
  <Stack Trace> :0 @ Int32 Godot.NativeCalls.godot_icall_5_593(IntPtr , IntPtr , System.String , IntPtr , System.String , IntPtr , UInt32 )()
                Object.cs:512 @ Godot.Error Godot.Object.Connect(System.String , Godot.Object , System.String , Godot.Collections.Array , UInt32 )()
                Manager.cs:13 @ void Manager._Ready()()

E 0:00:00.689   emit_signal: Can't emit non-existing signal "MySignal".
  <C++ Error>   Condition "!signal_is_valid && !script.is_null() && !Ref<Script>(script)->has_script_signal(p_name)" is true. Returned: ERR_UNAVAILABLE
  <C++ Source>  core/object.cpp:1195 @ emit_signal()
  <Stack Trace> :0 @ void Godot.NativeCalls.godot_icall_2_591(IntPtr , IntPtr , System.String , System.Object[] )()
                Object.cs:359 @ void Godot.Object.EmitSignal(System.String , System.Object[] )()
                ConcreteThing.cs:8 @ void ConcreteThing.MyMethod()()
                Manager.cs:14 @ void Manager._Ready()()

Steps to reproduce:
To verify this change in behaviour in the minimal reproduction project simply remove/add the generic type argument to the GenericThing class and ConcreteThing inheriting from it, then run the project.
Minimal reproduction project:

Generics Example.zip

@neikeq Sorry to ping, but if you happen to have the time to check whether this is an expected limitation I'd be much obliged.

Same is happening to me. I solved it temporarily by using native C# events instead of godot signals.

This seems to work quite well, even though I'd much prefer to use Godot's native signals to adhere to the conventions

In my case, ResourceLoader<T> is the abstract class and TileLoader inherits from ResourceLoader<Tile>.

That is a good idea I didn't have! I just took half an hour to try it out in my case and after reading up on a couple things about C# events sans Godot it works just like expected. The only thing I had figure out was to write a method which raises the event in the base class, since all subclasses need to be able to do that and C# doesn't allow this directly for events declared in the base class.

This happens with any generic class. Abstract has nothing to do with it.
Signal MySignal below will show up as missing
public class TypedSignaler<T> : Object
{
  [Signal] public delegate void MySignal();
}

If you were to move the signal out into a type-less base class, then it works!
public class TypedSignaler : Object
{
  [Signal] public delegate void MySignal();
}
public class TypedSignaler<T> : TypedSignaler { }

Sadly, that is not an option in many cases, so a fix is certainly needed.
This may even be a bigger issue. I could mean the CSharpScript or something is not fetched right for generic types. Keep an eye out for other bugs that could signal that that is the case.

It seems the GDMonoClass::get_all_delegates method does not retrieve delegates defined in a generic type. The problem seems to be the method mono_class_get_nested_types does not return anything in this case:
https://github.com/godotengine/godot/blob/4b4e92b3d4dfa850ed7d14202c3ec5e6b9646bc0/modules/mono/mono_gd/gd_mono_class.cpp#L446
The documentation for this method says:

This routine is an iterator routine for retrieving the nested types of a class. This works only if klass is non-generic, or a generic type definition.

So I think the way to fix this would be to check if the type is generic and in that case use the generic type definition instead of the generic type as the klass parameter. But I don't know how to get the generic type definition from the MonoClass *.

For GetGenericTypeDefinition we have to rely on C# helper methods. See how we do it here:
https://github.com/godotengine/godot/blob/3.x/modules/mono/glue/GodotSharp/GodotSharp/Core/MarshalUtils.cs
It seems mono_class_get_properties has the same comment about not working with generic types. We should check whether the listing of properties, methods and fields is also failing with generic types or not.

I'm only seeing that comment in the mono_class_get_nested_types method in the documentation I linked.
I tested again with a79e4d0ae5707f954f6422672cc9279f8165d91b (3.x) to check listing and it works everywhere (properties, fields and methods) except for delegates.

Delegates are, I'm pretty sure, closer to a static definition. That makes them more like enums and member classes than fields.

I must have misread the documentation for mono_class_get_properties. It's next to mono_class_get_nested_types so I probably read the latter's description by mistake.

authors: PhilG cgbeutler neikeq raulsntos serramatutu


text:
[3.3-rc8] Visual quality greatly degraded on mobile HTML5 from 3.2.3 to 3.3

Godot version: 3.3-rc8 (tried it with rc7 as well, upgraded to rc8 but problem persisted)
OS/device including version: Android 7.0, phone is a Asus Zenfone m1 or something similar, it's from 2018.
Issue description:
Our game is an educational game that must run on the web, on pcs or mobile. We begun testing out project with 3.3-rc7 to see if we could gain some performance, and while we did get a bit of an improve, the visual quality dropped a lot when accessing through mobiles.
I'm attaching an MRP with one logo, a group of images from one of the characters, and a button using styleboxflat and a dynamic font. They are exaclty the same as used in game, with the same import options (or lack of any customized import options), and I think the same configurations on the project settings, at least in the Display department.
As you can see from the images, or if you run the same MRP project in the browser and then set up ngrok or something similar to open it on your phone:

First run the project in 3.2.3 and access it from your phone and you'll see the images and the buttons are nice and crisp
Now run teh same project in 3.3 and access it from your phone and you'll se the images are very pixelated and even the font and button with the styleboxflat look bad

The only way I could kind of reproduce it on the PC browser was changing the export presset "Canvas Size Policy" to "None".  Then running the project on the web in the PC makes it really small and looks almost the same as the mobile one. But you can see the "Adaptative" mode is kind of working in the mobile version because when you change the project to "keep_width" it centers the canvas on screen. But  it might be related to this somehow?
When I change "Canvas Size Policy" to "Project" it stays crisp both on pc and mobile, but in mobile it doesn't matter what I choose in the "Aspect" property in the project settings, it doesn't adapt the content to mobile size in anyway, it always shows the full resolution so I can only see the beggining of the "Aliquest" logo. On the PC, if I resize the window, it doesn't adapt to it in any way, just like in the mobile browser. Is that how it is supposed to behave?
Steps to reproduce:

Open the MRP in Godot 3.2.3 and click to run in browser, set up ngrock or something to be able to open this page in your mobile phone. Open it there and see that the images are all nice and crispy
Open the MRP in Godot 3.3-rc8 and click to run in browser, set up ngrock or something to be able to open this page in your mobile phone. Open it there and see that the visual quality in general has greatly degraded.

Minimal reproduction project:
mrp_image_quality.zip
The set of images below shows the MRP as exported through godot 3.2.3 first and then by Godot 3.3-rc8

An easier way to reproduce it on PC that I didn't though about is just to export with "Canvas Size Policy" set to "Adaptative" and just resize your browser window T_T
Feels stupid that I didn't though about it before and wrote loads of paragraphs more than needed.

I'm working with @eh-jogos in this project and the same occurs in iOs (tested in iPhone 8).
Sending a screenshot of this issue reproduced in computer browser (running on Chrome browser, Mac OS):

You need to check Allow Hidpi in the Project Settings for hiDPI to work.

@Calinou

You need to check Allow Hidpi in the Project Settings and export the project again for hiDPI to work. Otherwise, a lowDPI fallback is used (which also improves performance). Previously, this setting didn't affact HTML5, but now it does.

Thanks a lot! This fixed it on mobile! Not really when just resizing the browser window size on PC, but I guess this is just forcing the issue and beside the point!
Again, thanks for the solution!

I amended the 3.3 changelog to mention this hiDPI setting change being required to restore hiDPI support (previously, it was always enabled, unlike other platforms).

authors: Calinou eh-jogos jpdurigan


text:
Setting RigidBody2D to MODE_CHARACTER turns off sleeping

Godot version
3.3 stable
System information
Linux
Issue description
If a rigidbody2d has sleeping set to true, but you change its mode to MODE_CHARACTER, then sleeping property currently set is bypassed, set to true and the body wakes up.
The manual states states only woken via

another body
apply_impulse or add_force

"...will not calculate forces until woken up by another body through, for example, a collision, or by using the apply_impulse or add_force methods."
If this is not the case, can the documentation be updated please?
Steps to reproduce

Create a rigidbody2d with sleeping set to true
In code change mode to MODE_CHARACTER

Minimal reproduction project
No response

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

authors: Calinou chucklepie


text:
Godot Engine Project Manager windows turns completely gray and a bit distorted on startup

Godot version
3.4.2-stable
System information
Windows 11, RTX 3070, OpenGL ES 3.0, Geforce Game Ready Driver v511.65
Issue description
Upon trying to launch godot engine, a cmd prompt and the godot engine project manager window opens up. Already a visual artifact shows up on the project manager window as a black square to the left and center of window as shown in screenshot.

When I try to click Open Asset LIbrary or Cancel or the Close button, godot turns into this.

This also leaves weird artifacts on other parts of my screen

This makes me unable to use the godot engine
Steps to reproduce
Run Godot.exe file
Try to press any buttons in the project manager window, or switch to another program (alt + tab)
Godot will now have a grey screen everywhere, but can notice slightly that the buttons still work in the background
Minimal reproduction project
No response

Does this occur every time? (I assume so, but just to make sure)
Does this occur on earlier Godot versions, i.e. 3.4.1 or more interestingly 3.3.x?

Occurs every time, I have tried the following versions:
3.4.1 (64-bit)
3.3.4 (64-bit)
3.3 (64-bit)
3.3.1 (64-bit)

@SeychellesDev Are you using a laptop with hybrid graphics (NVIDIA Optimus)?

I am using a desktop pc, with an Asus RTX 3070 Dual GPU, connected to 2 monitors, 1 via hdmi and 1 via display port.
Upon running godot engine with --video-driver GLES2, instead of the grey screen I get a Godot Engine Logo when I try to press a button, and nothing happens.

So after encountering the same issue with VoxEdit program, I realised it may be my system causing the error. I have an asus Prime X570 motherboard, and it installed some motherboard software when setting up my pc. This had caused issues with my windows before, although not similar. So I decided to uninstall anything to do with asus motherboard software, (Armoury Crate, RGB programs etc) and now Godot as well as VoxEdit works fine!
TLDR: Anyone having this same issue try uninstalling the ASUS programs that gets installed when you first setup your pc with a new motherboard. This fixed it for me!
Thank you all to those who tried to help.

authors: Calinou SeychellesDev mhilbrunner


text:
Viewport Node 'Escapes' editors 2d vieport

Operating system or device - Godot version:
Windows 2.1 stable Official (steam)
Issue description (what happened, and what was expected):
When using the viewport on a panel, if you drag the editors viewport to the left, the in scene viewport floats over the right side controls, If you drag to the right, the in scene viewport floats underneath the left side controls.
Steps to reproduce:
Use the attached project as I am unable to manually recreate it.
https://imgur.com/a/fU94S
Link to minimal example project (optional but very welcome):
Building Gen.zip

Another example by @Hinsbart, from the Platformer split screen demo:

Actually a duplicate of the good old #1840.

authors: Einlander akien-mga vnen


text:
GridMap - Crash when Octant size is set to 0

Operating system or device - Godot version:
Archlinux, custom-built godot version a75f5f039e31e20d985937f63cb2c8b90734160c
Issue description (what happened, and what was expected):
Two different, seemingly related bugs occur:
1.
When the parameter "Octant Size" of a gridmap is set to 0, the editor crashes. This only happens when there are already tiles set in the GridMap.
2.
When there are no tiles set and "Octant Size" is set to 0, it is set to 1 by godot, when I add a tile after that the program also crashes.
Steps to reproduce:
Download and open the example project linked below.

Set a tile in the gridmap, then set "Octant Size" to 0. It should result in a crash
Alternatively, set "Octant Size" to 0 before setting a tile. Godot sets it to "1". Then set a tile. This should also trigger a crash.

Link to minimal example project (optional but very welcome):
A minimal example:
https://my.mixtape.moe/vvntlo.zip

Actually, I cannot reproduce this issue.
Linix Mint 17.3 x64, latest dev build at that time (c05ff57)
Octant size is locked in range from 1 to some_number. In case of manual assign to zero, it goes to 1 automatically.

@vitvakatu Have you tried it with my project? The crash only occurs when at least one tile is set in the gridmap. If no tile is set, the lock is applied.

@jmf What have I done: I opened your project, open new_scene, then chose TileMap. I clicked on some tile in TileMap, than tried to change Octant Size for this tile to 0. You know the rest of the story. If I didn't do it wrong way, it seems to be really strange.

@vitvakatu With "set in the gridmap", I meant "placed on the gridmap within the scene".
Only selecting the tile isn't enough, it has to be placed in the scene to make this bug happen.
Sorry if I wasn't quite clear.

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

This bug doesn't occur in the latest version of godot any more.

authors: Noshyaar jmf vitvakatu


text:
Add tooltips on ButtonArrays

Godot 2.1 official:
I want to add a tooltip to buttons of a ButtonArray, but there are no way to do it, by script or in inspector. The only method is set_tooltip, but it is intented for the whole widget, not individual buttons.

Um, no Vbox/Hbox of buttons anyone?

Individual buttons as opposed to an array of them? Well, that'd work, but it doesn't solve @Zylann's issue.

ButtonArray behaves differently, I would have more stuff to setup for an HBox of buttons to behave the same way.

authors: Sslaxx Zylann bojidar-bg


text:
Using TextFiles results in faulty resource cache

Godot version
4.0 beta3
System information
Windows 10 x64
Issue description
Consider this code:
var tf = preload("res://text_file.txt

Normally the script will fail, because preload won't recognize the resource. However, if you open the txt file in the script editor, it will create an internal TextFile resource, which will take over the file's path in ResourceLoader's cache. This makes the preload() parse correctly in the editor, while it will still fail at runtime.
This is also the reason for #34607. TextFile hijacks the scene's path, so it can't be loaded as PackedScene.
Steps to reproduce

Create a text file with txt extension
Make sure it's open in script editor
In some script, preload the text file
Run the scene with the script

Minimal reproduction project
No response

I will have a look at this

Spent some time digging into & thinking about this one.
Is this just for text files? Are there other internal resources that could cause this issue?
Relevant lines for why this issue appears in preload() are in ResourceLoader::exists() are the following:
if (ResourceCache::has(local_path)) {
	return true; // If cached, it probably exists
}

And the only place where it appears that things get cached is at Resource::set_path(), by directly accessing ResourceCache::resources.
It seems like there lots of options here. Godot could expose TextFiles as a resource & have a ResourceFormatLoader for .txt files. This doesn't solve the problem of any other editor-recognized resources being used in the editor but not otherwise recognized. Are there others?
It's also possible to add a p_ignore_cache parameter to ResourceLoader::exists(), which really only fixes preload() but not really any potential in-editor vs in-app cache inconsistencies.
Could also have an option to not cache Resource as a Resource property, but that feels like a big change for a very specific issue.

Is this still reproducible in the latest master branch? (Note that some TextFile related changes were merged after 4.0 RC1).

Yes.

TextFile doesn't make any sense in Godot. Even though it extends Resource, it's not added to ClassDB and is missing a bind_methods implementation, meaning all data would be lost even if it hypothetically could be instantiated.
Doing resource operations such as Make Unique throws errors such as:
ERROR: Class 'TextFile' or its base class cannot be instantiated.
   at: (core/object/class_db.cpp:360)
ERROR: Condition "r.is_null()" is true. Returning: Ref<Resource>()
   at: duplicate (core/io/resource.cpp:269)
ERROR: Condition "unique_resource.is_null()" is true.
   at: _edit_menu_cbk (editor/editor_resource_picker.cpp:358)

In short, TextFile appears to be a hack and I think we should considered making it a proper Resource, registered in ClassDB with the text data exposed as a property.Otherwise, there is currently no way to ship pure text data in a Resource slot without hitting this issue.

TextFile was added in #19225 so I'm pinging @PaulB23 who has done recent work last year maintaining parts of the text editor system. I'm curious if there is any reason not to add TextFile to ClassDB and expose the property getters/setters for the text data.

It's not supposed to be used by user

Why? I strongly disagree. It's a resource so it should act like a resource. If the name is bad we can pick another name like TextResource or TextData.
I use TextAsset in unity all the time. Why would this not be allowed in Godot?
having the TextFile resource type deliberately unexposed causes bugs, not solves bugs.

For text files you can use FileAccess directly (loading text files is a one-liner). TextFile does not provide any useful functionality, it's just editor hack.

authors: KoBeWi PucklaMotzer09 akien-mga anvilfolk lyuma


text:
IPv6 for Godot 2.1.x

The recently-implemented IPv6 support in the master branch seems to behave, at least @punto- reports that some guys were able to publish their iOS game without any trouble (so Apple did not complain about missing support - and I suppose the game worked too :)).
There have been quite a few commits about this, so instead of trying to cherry-pick them myself, I'd like someone who understands this stuff to do it :)
@Faless Would you mind preparing a pull request to the 2.1 branch to add all the IPv6-related commits?
You can cherry-pick with git cherry-pick -x <commit-hash> - the -x part adds the hash of the original commit to the description of the cherry-picked commit, I'm using this as a convention for better traceability.

@Faless Would you mind preparing a pull request to the 2.1 branch to add all the IPv6-related commits?

Sure, no problem, I'll start cherry picking and let you know ASAP @akien-mga

Closing as the PR was merged

authors: Faless akien-mga bojidar-bg


text:
Inconsistent Inspector panel behavior when clicking a node vs. a file

Godot version
v4.0.stable.official [92bee43ad]
System information
macOS 13.2.1 (22D68), 16 inch MacBook Pro M1 Max
Issue description
I am constantly getting momentarily confused about what's appearing in the Inspector tab. If I single click a node in the scene tree, that node becomes selected and the information for that node is in the Inspector tab as I would expect. HOWEVER if I single click a file in the FileSystem tab, all that happens is that the file becomes visually selected - it does not change the content of the Inspector tab despite my having just clicked it and despite there being a blue outline around the entire FileSystem tab's inner content indicating that focus is there.
Steps to reproduce
This screenshot isn't terribly exciting, but it shows what happens after I clicked on the "icon.svg" file in the FileSystem tab. Note that the Inspector is still showing the information for a node I had selected previously. Also note that a quick glance at this window makes it appear as if two different objects are selected at the same time - the CanvasGroup node in the scene, and also the icon.svg file.

This is very confusing, IMO.
There are multiple problems here, I think:
One is that single clicking on a file in the FileSystem tab only selects it in that tab but doesn't open the information for that file in the Inspector. I instead have to double click file objects to show them in the Inspector tab - unlike everything else which is a single click (as far as I know).
The other problem is that multiple things can look selected at the same time even when they are not. In the screenshot above, the CanvasGroup node shouldn't look selected because I had just clicked on the icon.svg file and that is where my focus is. You could argue that this is fine because I didn't "fully select" icon.svg by double clicking it - but indeed even when I do double click icon.svg to "open" the file, now it shows up only in the inspector but nothing else has changed and no new editor has appeared - it still looks like CanvasGroup is selected as well except now the Inspector properties don't make sense. And even worse, because my mouse happened to enter the main editor zone of the window, there's now a thin blue outline around it making me think the editor context is active!

I realize that there's probably some complication here because double clicking a file is how you "open" it and I don't think I would want a single click of a scene file to immediately open it up in a new tab (although... maybe that wouldn't be terrible?), but this is fuzzy when it comes to other types of files like images and resources which appear to "open" in the inspector.
I don't entirely know what the solution is, just that the current situation can be confusing and disorienting.
Minimal reproduction project
Any project can reproduce this.

It's to prevent loading things by accident when selecting them, otherwise it'd work different from when clicking a scene in the file systen

Yes, I mentioned that myself - I assumed this is why. That doesn't change the fact that this is extremely confusing and some aspect of the behavior should be fixed, IMO. Even just clearing prior selections and clearing the Inspector when I single click on a file would be an improvement. That would at least remind me to double click to "open" that file if I want to view it in the inspector. Clicking on a different file should once again reset everything. There shouldn't be multiple things on screen marked in blue "selected" state that don't match what the Inspector is showing.

Also clearing the inspector when selecting a file would remove an important feature, you couldn't drag and drop files into it any longer

See here for an explanation

I'm not sure why you're being so dismissive? There are solutions to this. This isn't an impossible to solve problem. Fire up Unity and select a scene object there and then select a different one in the project navigator - boom it deselects your scene object and immediately shows you what you clicked on in the inspector. This is logical and consistent and there's only one "thing" selected at a time.
The problem of drag and dropping files is also totally solvable - and indeed somehow magically works in Unity, too! When I'm dragging, I still have the mouse button down. It doesn't need to change the selection at that instant! Wait until I lift the mouse button. In virtually all other software, mouse down is only a "highlighting" effect and the selection doesn't change until mouse up. Godot is the one doing the odd thing here.

This doesn't need a solution, this is by design, please don't come into the bug report dead set on that you're right, it's not helpful

Inspector does not show currently selected objects, it shows currently edited objects. Scene by itself is not displayed as an object in the inspector, but its nodes are. So as you edit scene, selecting nodes makes them active as edited objects. Selecting a file does not open it for editing, but opening it does make it an edited object, and thus makes it appear in the inspector.
In short, you should not look at it in terms of a focus, but in terms of an editing context. Making files editable with a single click is not impossible to implement, though. You should open an enhancement proposal, explaining why that would be an improvement to your workflow.

This doesn't need a solution, this is by design, please don't come into the bug report dead set on that you're right, it's not helpful

This is extremely arrogant. Bad usability is a bug. Does this project want feedback or not?

I think what @AThousandShips wants to say is that while it may not be what you intuitively expect to happen, there is a reason for this behavior, and it works and makes sense to other users.
That said, @AThousandShips, you did put it in a rather dismissive way. Please be mindful that different users may find different workflows frustrating, even if it makes sense to you.

If the correct thing to do is to file this as an enhancement request, then sure, I can do that, but personally this feels more like a bug - I select something and the prior selection is not being unselected so now I have two things selected. I thought something like an enhancement proposal was for huge features or something. I don't know who is supposed to decide which things are bugs vs. enhancements - especially when it comes to usability type of stuff which will always be somewhat subjective.

@BigZaphod Well, I am here to help you with that decision :) And so are other people with the Member badge. Everything worth improving can be argued to be considered a bug, but the important difference here is that the current behavior is intended and is working as designed. Also, usability is not an exact science and it doesn't always happen to have solutions that apply universally. There is a reason why Godot clicks with people where others engines don't, and there is a reason why you clicked better with Unity's behavior in this case - everyone thinks differently, and tools that work for some may not work for others.
As such, usability improvements are usually about making sure that we don't make people who are used to or prefer Godot's ways uncomfortable, while allowing customization options or alternative tools for those who need them. While you may feel strongly about this issue, we can't consider it a bug based only on that. And a proposal is the best place to discuss that, and to turn your issue into something actionable.

@YuriSizov ok I'll post it as a proposal, I guess, but this isn't something I'm going to go to war over or even care that deeply about. I only use Godot as an intermittent hobby and it was just a suggestion and a data point that I was hoping could be used to make things better someday.
I'm honestly not in a good mood right now having been jumped all over for this after taking 30 minutes to write it up in the first place and now still discussing the meta 30 minutes later. It honestly puts me off the idea of submitting issues in the future. I was also going to raise one about the difficulty of navigating the 3D editor using just a MacBook trackpad, but this experience makes me think that's not worth reporting that either because someone will probably say it wasn't designed for that use case so I am not justified even bringing it up or something like that. 😕

You are justified to bring up any issue that you face. We use this repository only for bug reports, and we use a separate repository for enhancements, because we have very many of both and need some organization. Making a proposal issue or opening a proposal discussion is just as valid to bring an issue to the attention of Godot users and contributors.
But you have to keep in mind that others may not share your concerns and may be happy with things as they are. That's always a possibility, especially with UX.
It's not a big deal that you picked a wrong repository to open your issue. GitHub doesn't make it easy for us to manage such a large project, so we can't very effectively guide everyone to the right place and save you time. But that's why I am here talking to you, so you know what to do in the future.

authors: AThousandShips BigZaphod YuriSizov


text:
Editor preview of the contents of a TabContainer is incorrect for every tab except the first one

Godot version
v4.0.stable.official [92bee43ad]
System information
Linux
Issue description
Creating a tabbed interface for options, the Y position for elements inside the Audio tab (second tab) appear to be incorrect in comparison to the Graphics tab (first tab).
Compare:

That said, at runtime these appear to be in the correct positions.
Compare:

Steps to reproduce
A minimum scene tree:
Control
    TabContainer
        Control
            Label
        Control
            Label

Where the labels have the same position according to Layout/Transform.
74653_demonstrator.zip should be a minimal reproduction.

Yeah, and I'm pretty sure this was reported already, but I can't find it. So we can keep this one for now.

The minimal project is empty.

Here is an MRP:
TabContainer_74653.zip
Steps:

Open control.tscn.
Use the toggle visibility button in the Scene dock to show the ColorRect or the TextureRect.
The ColorRect doesn't show at all, and the TextureRect appears at the wrong position and scale.
Use the TabContainer's current tab property in the Inspector to see what they should look like.
After that, they will be correct when changing visibility, so close and reopen the scene to reproduce again.

authors: KoBeWi Sslaxx YuriSizov kitbdev


text:
Editor menu mouse clicks don't register unless Single Window Mode is enabled (DisplayServer regression)

Godot version
4.0.3 rc1
System information
Windows10
Issue description
UPDATE - windowsKey + arrowKey does not seem to be the cause. Issue is happening regardless.
Editor menu mouse clicks do not always work. It seems to only happen if I snap the godot application with windowsKey + arrowKey (keyboard keys capture in lower left of video). Seems rather weird if this is the case, but I can repeat the issue consistently.
Note:

this was happening randomly in 4 beta, final, etc but I could never get it to occur consistently
this bug does not happen in 3.5.2 stable

Please see video for steps.
https://user-images.githubusercontent.com/132544925/236126715-60843be2-7a65-411f-9952-c5139aeabba8.mp4
Steps to reproduce

create a new project
follow steps in attached video

Minimal reproduction project
N/A

Can you reproduce this after enabling Single Window Mode then restarting the editor?

Turning on Single Window Mode seems to work. When I turned it back off, the issue happened again.
hmm. I played around with it a bit more, and it's happening now even when I don't snap the application with windowsKey+arrowKey. I will update the issue as that's doesn't seem to be the issue.

Sounds related to #61758

Closing issue and will update https://github.com/godotengine/godot/issues/61758 as related

authors: Calinou KoBeWi someThrowAway1900


text:
AnimationPlayerEditor doesn't preview the Animation when seeking Animation Playback Tracks

Tested versions

Reproducible in 4.2 stable.
Same error doesn't occur in 4.1.3 (previews work as they should)

System information
Windows 11 - Godot 4.2 stable
Issue description
When I create a regular animation of any property it will playback in the editor fine as I move the play head. However, if I add these individual animations as Animation Playback Tracks to a new AnimationPlayer, moving the head no longer plays previews.
This is inconvenient as I wish to sync different object animations and have to do it blind.
Steps to reproduce
Create a regular animation, then add the entire Animation Player to a new animation player as 'Animation Playback Track'. Try to move playhead. The preview of the animation will not play.
Minimal reproduction project (MRP)
N/A

The original submission covers it, but I made this gif before realizing the issue was reported already, so adding it in case it's helpful. The gif shows the scrubbing working on 4.0.2 but not 4.2.


text:
Adding community translations is impossible and easier in closed Unreal/Unity

Tested versions
Please stop using the dreadful .translation format for translations by default. Instead make it easy to access the translations by default for modders and community translators.
https://github.com/bruvzg/gdsdecomp/issues/90
System information
windows 10 any
Issue description
Godot is harder to mod than Unity/Unreal
Steps to reproduce
Use https://github.com/bruvzg/gdsdecomp to get translations from compiled game. fail
Minimal reproduction project (MRP)
Use https://github.com/bruvzg/gdsdecomp to get translations from compiled game. fail.

This is clearly not following our Code of Conduct: https://godotengine.org/code-of-conduct/
If you're not willing to be constructive, we're not going to waste time on our end.

authors: akien-mga ghostlyghastly


text:
AnimationPlaybackTracks no longer functioning as intended

Tested versions

Reproducible on 4.3.dev.gh [2efbc6bfb]
Reproducible on 4.2.2-rc3 and 4.2.2-stable
Not reproducible on 4.2.2-rc2 and before

System information
Godot v4.2.2.stable - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Laptop GPU (NVIDIA; 31.0.15.5186) - 12th Gen Intel(R) Core(TM) i7-12700H (20 Threads)
Issue description
While in-editor seeking of AnimationPlaybackTracks now works as it should, actually playing the animation that uses an AnimationPlaybackTrack no longer plays the referenced animation properly. It also does not seem to work when running the project with this animation setup.
https://github.com/godotengine/godot/assets/79013106/0cb57735-d74a-4169-8af8-8e3e84cce395
Steps to reproduce

Create an AnimationPlayer
Create any animation
Create another AnimationPlayer
Insert AnimationPlaybackTrack and reference the animation in step 2

Minimal reproduction project (MRP)
This is project in the video, it has the steps above already done.
AnimPlaybackTrackBug.zip

The problem seems to be in scene/animation/animation_mixer.cpp at line 1611
a->track_get_key_indices_in_range(i, time, delta, &to_play, looped_flag)
doesn't seem to return anything if the clip lands at 0 seconds on the timeline. I don't really have time to dig any deeper, but hopefully that give someone a starting point

The problem seems to be in scene/animation/animation_mixer.cpp at line 1611

It is not related since immediately after playback it never goes through line 1661.
This is actually due to some missing processing that should be taken into account for the internal seek (meaning immediately after playback). I have sent https://github.com/godotengine/godot/pull/90960 to fix that, so please check it if possible.

authors: TokageItLab antourenein sketchyfun


text:
Change the theme forget your config in "custom"

Tested versions
v3.6.beta5.official [2a347ab86]
System information
w10 64
Issue description
In the editor options there is a theme called "custom".
I customized that theme with my highlight colors.
Next, I selected the "adaptive" theme to see what it would look like.
Then I went back to my "custom" theme and... surprise, all your highlight settings have been forgotten and now you'll have to do it again.
What is the purpose of this "custom" theme if it doesn't save your settings?

Steps to reproduce
It is only necessary to define a custom color for the "custom" theme.
Now activate the "adaptive" theme (for example).
Go back to the "custom" theme, you will notice that your customization has been forgotten.
Minimal reproduction project (MRP)
...

"Custom" indicates that there is not a preset that exactly matches all the current values of individual settings. If you change at least one individual setting, then it is already considered "Custom". When you select a standard theme, all settings are reset to the theme values. So a less confusing term would be "preset" rather than "theme".

Changing how where custom highlighting colors are set would break people's existing syntax themes upon upgrading, so I don't think it's a good fit for 3.x where stability is highly valued.

authors: Calinou Torguen dalexeev


text:
[DOCS] Update 12 VisualScript* nodes

Updated or added a number of node descriptions, including listing the input/output ports. As with the last PR, hopefully this will help us zero in on VS documentation standards.

looks nice from my side :)

Updated the wording. Holding off on the rest for now as discussed.

source: gharchive/pull-request

authors: Grosskopf cbscribe


text:
Inspector folding fix

I've fixed inspector folding property(EditorSettings->Interface->Editor->Disable Inspector Folding)

It will now can be apply, without editor restart
It will actually hide the property folding controls(as it intended to be)

when disabled

when enabled

Hmm.. I think Collapse and Expand shortcuts must be disabled when this property enabled...

Ok, so, now when Folding is disabled
The Collapse and Expand labels will also be disabled

I don't really get the point of this option? Isn't the option to expand all by default sufficient? I don't think it hurts the workflow to have the possibility to fold things. Having both an option to expand all and an option to disable folding seems redundant.

So this flag should be removed from editor instead ?

authors: Chaosus akien-mga


text:
Fixed text entry is going in reverse

Fixed text entry is going in reverse, this undoes what seems to be a mistake in #20400 and fixes #21061

Thanks!

@DualMatrix Also thanks.  X)  Ran a rebuild of it, and it looks good.

This fix is actually not quite ideal. There's an issue editing exported Dictionary/Array. (text box is unfocused while typing in String property, etc.) EditorPropertyDictionary/Array must have support for the extra arg too.

authors: DualMatrix Noshyaar akien-mga avencherus


text:
Fix OpenGL error when generating radiance

Fixes: #40444
Looks like my hardware just silently ignored the fact that the texture was the wrong type.
Seems to work fine for me. But I was unable to reproduce the linked error.

There seems to be a second occurrence of glFramebufferTextureLayer in that file (and those are the only ones in the codebase, apart from glad code that defines it) that probably needs a similar treatment:
drivers/gles3/rasterizer_storage_gles3.cpp
2043:                   glFramebufferTextureLayer(GL_DRAW_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, sky->radiance, 0, j);
2172:                   glFramebufferTextureLayer(GL_DRAW_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, sky->radiance, 0, lod);

There seems to be a second occurrence of glFramebufferTextureLayer in that file (and those are the only ones in the codebase, apart from glad code that defines it) that probably needs a similar treatment:

The other occurence is correct. It is used when we are using a texture array for radiance. This issue resulted from copy-pasting that code.

@akien-mga Should be good to merge once CI passes.

Thanks!

authors: akien-mga clayjohn


text:
Rename get_surface_material to get_surface_override_material

The surface material property of MeshInstance3Ds overrides the Material for a given surface. It behaves the same as override_material just on a per-surface basis. This has been poorly communicated to users who often mix up MeshInstance3D.get_surface_material() with Mesh.surface_get_material(). This becomes especially problematic when users set a material on the mesh and then try to get it from the MeshInstance3D as in https://github.com/godotengine/godot/issues/31558
Renaming the property to reflect that it is an override material is consistent with the override_material property of GeometryInstance3D and makes it clear that it is not the same things as a mesh material
Partially implements: https://github.com/godotengine/godot-proposals/issues/2589
Implements: https://github.com/godotengine/godot/issues/31558#issuecomment-580974735

Sounds sensible to me. :+1:

Thanks!

while this is a great improvement. I hope you have considered these options:

naming the mesh resource surface materials "default_surface_materials" if you want it to be disambiguated from both sides.
instead of "surface_override_material" it could be "instance_surface_material" this communicates effectively that it is unique to each instance and future proofs it if we ever switch from an override to an overlay method.

authors: akien-mga clayjohn lawnjelly lukostello


text:
GLES3: Basic 3D rendering of Unshaded objects and sky

This continues the work on the GLES3 renderer by (each commit):

getting Uniforms in custom materials working and by getting the sky background drawing.
implementing the Basic Scene Shader
Adding drawing of unshaded meshes based on the Vulkan Mobile Renderer

The next major step is to add lights to the renderer which will require substantial changes to what is already there.
Current state of GLES3:

Comment from initial commit:
The only thing that may need a second set of eyes is my change to is_low_end() Previously it didn't work and was just commented out. I need it becuase the GLES3 shaders are slightly different from the Vulkan GLSL shaders. I made it so GLES3 returns true on low end, but vulkan-mobile no longer returns true. This makes sense for most features, but we may want to disable some features (gi etc.) when vulkan-mobile is used. So we may need another flag is_modern or we may want to return an enum instead of a bool.

GL_MULTISAMPLE seems not to be defined on WebGL 2.0. See https://github.com/emscripten-core/emscripten/issues/7898#issuecomment-456854011

@Akien This is ready to go now. Its getting to be a sizeable PR, so I would prefer to merge it now and make another PR for lights rather than add more to this.

Thanks!


text:
Properly expose TEXTURE_PIXEL_SIZE in Opengl3 renderer

This fixes an unreported bug where shaders would error whenever TEXTURE_PIXEL_SIZE was used in the Opengl3 renderer.

Thanks!


text:
EditorNode3DGizmoPlugin: Add GDVIRTUAL_CALL for get_gizmo_name and get_priority

When get_gizmo_name and get_priority are overridden in a GDExtension (godot-cpp) class that extends EditorNode3DGizmoPlugin and this gizmo is registered in Godot with add_node_3d_gizmo_plugin, the two overridden functions will not be called.
For example, in the case of get_gizmo_name, the gizmo will still be displayed as "Unnamed Gizmo" in the Gizmos menu.
This PR fixes that by replacing the script instance check with a GDVIRTUAL_CALL. The overridden functions in GDExtension will be called correctly. Fixes #66992

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

authors: akien-mga alessandrofama


text:
Add option for root node name on Import 3D scene window

Fix #6822

Added option for root node name, not just taking filename as @reduz commented https://github.com/godotengine/godot/issues/6822#issuecomment-253791761


text:
Text resource loader fixes

Moved the order of progress update to after the actual resource loading to give better % numbers.
Fix a bug introduced by #67714, which broke cache ignoring.

Thanks!

authors: akien-mga reduz


text:
Allow EditorExportPlugins to provide export options

Basically duplicates get_export_options from EditorExportPlatform to EditorExportPlugin and sets things up for scripting.
This allows export plugins to to have export preset specific options that also show up in the export dialog.
Example (the Dotnet options are added from from the CSharpExport plugin):

Open issue: From scripts the options are always added to the very end of the options list so users always have to scroll to the very end to access them

Thanks!

@RedworkDE There's a bug with restoring the saved values for the editor export plugin options from the preset; see https://github.com/godotengine/godot/pull/78958#issuecomment-1618994224

authors: RedworkDE akien-mga m4gr3d


text:
Add allow_search property to ItemList and Tree to control incremental search

Implementing https://github.com/godotengine/godot-proposals/issues/4682.
This makes Tree and ItemList consistent with PopupMenu, which has the allow_search property to control incremental search, which is sometimes not desired.  Default is true to preserve existing behavior.
This was needed for my own game, since I wanted the player to open a tree menu while playing to spawn entities, but input was read by the incremental search and interfered with navigation.
I've done basic testing for both nodes with and without search to ensure it works as expected.
Production edit: Closes https://github.com/godotengine/godot-proposals/issues/4682.

Try not to edit the structure of class ref files manually. Use doctool instead. See this article.

Thanks!

authors: YuriSizov akien-mga needleful


text:
Fix C# "out of sync" notice with external editors

The notice introduced in #85869 wasn't being dequeued when building from an external IDE. This PR fixes it by changing what triggers our reevaluation of the last valid build time. We used to react only to Godot's internal build process. We're now reacting to assembly reload, which is triggered both by building from Godot, and from the watcher.
Thanks @Delsin-Yu @zaevi for pointing out the issue.

Thanks!

authors: akien-mga paulloz


text:
FBX: Print ufbx load warnings on import

This PR adds printing of warnings reported by ufbx when importing files. This could help in diagnosing errors when users try to import half-broken files with half-broken results. ufbx itself is quite silent about warnings, so these should only be issued when there's something truly wrong with the file, in a way that might make the imported scene broken in some ways.

Initial dataset testing indicates that even though errors are rare, some badly behaving files will spam an astounding amount of errors (one file so far has issued a whopping 29088 warnings). I'll probably implement a per-type warning limit to ufbx to prevent such cases, but for now (and maybe even in general) we'd want to limit the maximum amount of warning spam on Godot side as well.

Limited the maximum errors to 10 per type. Also added element names (like nodes or meshes that prompt the warning) to the warnings.

Thanks!

authors: akien-mga bqqbarbhg


text:
ResourceLoader: Fix handling of uncached loads

CACHE_MODE_IGNORE_DEEP is checked in addition to CACHE_MODE_IGNORE to determine if a load is uncached. This avoids crashes in uncached loads due to prematurely freed load tasks.
Cached load tasks are isolated (not registered in the task map ever). This avoids regular loads from reusing in-flight cached loads, which is not correct.

Thanks!

Since we merged in the latest master a few days ago, we had errors in our game every now and then (like "play the game for at least 5 minutes and they started occurring" kind of frequency). They were in the resource_parser_text and errors like "could not parse" or "error loading dependency" or even "no resource found at path". We use the threaded resource loader quite a lot, so this could be a rare problem for others...
We traced the problem back to this PR through bisecting. And while looking at the changes I found it odd that the new code returns the load_token even when it is invalid:
https://github.com/godotengine/godot/blob/82cedc83c9069125207c128f9a07ce3d82c317cc/core/io/resource_loader.cpp#L476-L481
while the old code only returned in an else (so only when the token is valid) and otherwise populated the load_token later on in the function before returning:
if (!load_token.is_valid()) {
	// The token is dying (reached 0 on another thread).
	// Ensure it's killed now so the path can be safely reused right away.
	thread_load_tasks[local_path].load_token->clear();
} else {
	if (p_cache_mode != ResourceFormatLoader::CACHE_MODE_IGNORE) {
		return load_token;
	}
}

So I tried just adding the else back to the condition and the errors went away:
if (!load_token.is_valid()) {
	// The token is dying (reached 0 on another thread).
	// Ensure it's killed now so the path can be safely reused right away.
	thread_load_tasks[local_path].load_token->clear();
} else {
	return load_token;
}

I am totally unsure if that is correct in any way, though 😀 Can you look into this @RandomShaper ?

Excellent catch. I'm preparing a PR that fixes a few other issues and will include the fix there. Thank you.

authors: RandomShaper akien-mga mrTag


text:
ResourceLoader: Fixup management of thread-specific status

Allows the message queue override to flush after loading each resource, which was the original intent.
UPDATE: The effect of this is that external resources that could be successfully loaded have their deferred setup calls run regardless the load will be reported as failed. This is important because if another simultaneous load will get them from cache while they still exist, they will be guaranteedly "complete." Moreover, such behavior was also the case before those calls were flushed in loader threads. Formerly, they were flushed on the main thread so if some resource would survive an overall failed load, they'd still get that "completeness" guarantee.
Removes a redundant call to mark the thread as safe-for-nodes.

Thanks!

authors: RandomShaper akien-mga


text:
Add linux-bionic RID Export Option

Supersedes #97901
Resolves #97775
@raulsntos hopefully I'm homing in to your design goals!
This time around I just replace the RID, as you mentioned, with the linux-bionic one when it's enabled for Android, which should be the only platform that the option shows up for.

I tried this PR and enabled the linux bionic option, however it still failed to build when exporting for Android NativeAOT.
The PrivateSdkAssemblies ItemGroup is required for _ComputeAssembliesToCompileToNative
/home/luo/.nuget/packages/microsoft.dotnet.ilcompiler/8.0.10/build/Microsoft.NETCore.Native.Publish.targets(76,5)

After adding <PublishAotUsingRuntimePack >true</PublishAotUsingRuntimePack>, still failed to build but the error message is diffrent:
MSB3073: The command ""clang" "/home/luo/new-game-project/.godot/mono/temp/obj/ExportDebug/linux-bionic-arm64/native/New Game Project.o" -o "/home/luo/new-game-project/.godot/mono/temp/bin/ExportDebug/linux-bionic-arm64/native/New Game Project.so" -Wl,--version-script=/home/luo/new-game-project/.godot/mono/temp/obj/ExportDebug/linux-bionic-arm64/native/New Game Project.exports -Wl,--export-dynamic -gz=zlib -fuse-ld=lld /home/luo/.nuget/packages/microsoft.netcore.app.runtime.nativeaot.linux-bionic-arm64/8.0.10/runtimes/linux-bionic-arm64/native/libbootstrapperdll.o /home/luo/.nuget/packages/microsoft.netcore.app.runtime.nativeaot.linux-bionic-arm64/8.0.10/runtimes/linux-bionic-arm64/native/libRuntime.WorkstationGC.a /home/luo/.nuget/packages/microsoft.netcore.app.runtime.nativeaot.linux-bionic-arm64/8.0.10/runtimes/linux-bionic-arm64/native/libeventpipe-disabled.a /home/luo/.nuget/packages/microsoft.netcore.app.runtime.nativeaot.linux-bionic-arm64/8.0.10/runtimes/linux-bionic-arm64/native/libstdc++compat.a /home/luo/.nuget/packages/microsoft.netcore.app.runtime.nativeaot.linux-bionic-arm64/8.0.10/runtimes/linux-bionic-arm64/native/libSystem.Native.a /home/luo/.nuget/packages/microsoft.netcore.app.runtime.nativeaot.linux-bionic-arm64/8.0.10/runtimes/linux-bionic-arm64/native/libSystem.Globalization.Native.a /home/luo/.nuget/packages/microsoft.netcore.app.runtime.nativeaot.linux-bionic-arm64/8.0.10/runtimes/linux-bionic-arm64/native/libSystem.IO.Compression.Native.a /home/luo/.nuget/packages/microsoft.netcore.app.runtime.nativeaot.linux-bionic-arm64/8.0.10/runtimes/linux-bionic-arm64/native/libSystem.Security.Cryptography.Native.OpenSsl.a --target=aarch64-linux-android21 -g -Wl,-rpath,'$ORIGIN' -Wl,--build-id=sha1 -Wl,--as-needed -Wl,-e0x0 -pthread -ldl -lz -llog -lm -shared -Wl,-z,relro -Wl,-z,now -Wl,--eh-frame-hdr -Wl,--discard-all -Wl,--gc-sections -Wl,-T,"/home/luo/new-game-project/.godot/mono/temp/obj/ExportDebug/linux-bionic-arm64/native/sections.ld"" exited with code 1. /home/luo/.nuget/packages/microsoft.dotnet.ilcompiler/8.0.10/build/Microsoft.NETCore.Native.targets(366,5)

@atlasapplications  Thank you for your guidance. I encountered two errors again ( tested in arch linux)

(Resolved) The project name cannot contain spaces. Otherwise, there will be the following errors:

...
--version-script=/home/luo/new-game-project/.godot/mono/temp/obj/ExportDebug/linux-bionic-arm64/native/New Game Project.exports
clang: error: no such file or directory: 'Game'
clang: error: no such file or directory: 'Project.exports'

It seems dotnet is still using my linux clang toolchain, but I have alreay set ANDROID_HOME and ANDROID_NDK_HOME

  1>ld.lld : error : cannot open crtbegin_so.o: No such file or directory [/home/luo/newgameproject/NewGameProject.csproj]
     1>ld.lld : error : unable to find library -llog [/home/luo/newgameproject/NewGameProject.csproj]
     1>ld.lld : error : cannot open /usr/lib/clang/18/lib/linux/libclang_rt.builtins-aarch64-android.a: No such file or directory [/home/luo/newgameproject/NewGameProject.csproj]
     1>ld.lld : error : unable to find library -l:libunwind.a [/home/luo/newgameproject/NewGameProject.csproj]
     1>ld.lld : error : cannot open /usr/lib/clang/18/lib/linux/libclang_rt.builtins-aarch64-android.a: No such file or directory [/home/luo/newgameproject/NewGameProject.csproj]
     1>ld.lld : error : unable to find library -l:libunwind.a [/home/luo/newgameproject/NewGameProject.csproj]
     1>ld.lld : error : cannot open crtend_so.o: No such file or directory [/home/luo/newgameproject/NewGameProject.csproj]
     1>clang : error : linker command failed with exit code 1 (use -v to see invocation) [/home/luo/newgameproject/NewGameProject.csproj]

I can run the follow command and compile successfully by setting CppCompilerAndLinker:
dotnet publish -r linux-bionic-arm64 -c ExportDebug -p:CppCompilerAndLinker=$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -p:PublishAOT=true -p:DisableUnsupportedError=true -p:PublishAotUsingRuntimePack=true

if adding $ANDROID_NDK_HOME/toolchains/llvm/prebuilt/linux-x86_64/bin/ to PATH the follow works, too:
dotnet publish -r linux-bionic-arm64 -c ExportDebug -p:PublishAOT=true -p:DisableUnsupportedError=true -p:PublishAotUsingRuntimePack=true

However, I believe even with correct environment variables it still can't be successfully built in Godot.

Adding the lib prefix and copying the .so into the apk will result  runtime errors:
2024-11-19 13:18:15.390 31066-31174 godot                   com.example.game                     E  ERROR: Can't open dynamic library: libmonosgen-2.0.so. Error: dlopen failed: library "libmonosgen-2.0.so" not found.
2024-11-19 13:18:15.390 31066-31174 godot                   com.example.game                     E     at: open_dynamic_library (platform/android/os_android.cpp:240)
2024-11-19 13:18:15.391 31066-31174 godot                   com.example.game                     E  ERROR: Can't open dynamic library: /data/data/com.example.game/cache/data_NewGameProject_android_arm64/NewGameProject.so. Error: dlopen failed: library "NewGameProject.so" not found.
2024-11-19 13:18:15.391 31066-31174 godot                   com.example.game                     E     at: open_dynamic_library (platform/android/os_android.cpp:240)
2024-11-19 13:18:15.391 31066-31174 godot                   com.example.game                     E  ERROR: .NET: Failed to load hostfxr
2024-11-19 13:18:15.391 31066-31174 godot                   com.example.game                     E     at: initialize (modules/mono/mono_gd/gd_mono.cpp:549)

Instead, after removing the check, I successfully build and run on Android:
diff --git a/platform/android/export/export_plugin.cpp b/platform/android/export/export_plugin.cpp
index 9545d74730..c5282bdef6 100644
--- a/platform/android/export/export_plugin.cpp
+++ b/platform/android/export/export_plugin.cpp
@@ -755,11 +755,6 @@ Error EditorExportPlatformAndroid::store_in_apk(APKExportData *ed, const String
 }

 Error EditorExportPlatformAndroid::save_apk_so(void *p_userdata, const SharedObject &p_so) {
-	if (!p_so.path.get_file().begins_with("lib")) {
-		String err = "Android .so file names must start with \"lib\", but got: " + p_so.path;
-		ERR_PRINT(err);
-		return FAILED;
-	}
 	APKExportData *ed = static_cast<APKExportData *>(p_userdata);
 	Vector<ABI> abis = get_abis();
 	bool exported = false;

I think removing the check is a simple solution If  it's not necessary.

@beicause I don't know if we can remove that check, the error message seems to imply this is a restriction of the Android platform. The @godotengine/android team can confirm if this check is safe to remove.
Alternatively, if we need the native library to start with a lib prefix we can probably rename it before copying it and add a special case to the try_load_native_aot_library function for Android like so:
diff --git a/modules/mono/mono_gd/gd_mono.cpp b/modules/mono/mono_gd/gd_mono.cpp
index c81aa91fa5..9de762a408 100644
--- a/modules/mono/mono_gd/gd_mono.cpp
+++ b/modules/mono/mono_gd/gd_mono.cpp
@@ -416,6 +416,8 @@ godot_plugins_initialize_fn try_load_native_aot_library(void *&r_aot_dll_handle)
 	String native_aot_so_path = GodotSharpDirs::get_api_assemblies_dir().path_join(assembly_name + ".dll");
 #elif defined(MACOS_ENABLED) || defined(IOS_ENABLED)
 	String native_aot_so_path = GodotSharpDirs::get_api_assemblies_dir().path_join(assembly_name + ".dylib");
+#elif defined(ANDROID_ENABLED)
+	String native_aot_so_path = "lib" + assembly_name + ".so";
 #elif defined(UNIX_ENABLED)
 	String native_aot_so_path = GodotSharpDirs::get_api_assemblies_dir().path_join(assembly_name + ".so");
 #else

This is because since https://github.com/godotengine/godot/pull/88803 we are including every native library .so into the lib directory of the APK. So we should use only the filename to open the native library and Android will know where to find it.

@beicause I don't know if we can remove that check, the error message seems to imply this is a restriction of the Android platform. The @godotengine/android team can confirm if this check is safe to remove.

From a quick search, that indeed seems to be an Android specific restriction, so I don't think we can remove the check.
@raulsntos I'd echo your proposal of renaming the library instead and updating the loading logic.

@beicause This is my previous project, I used #86791 to export Android aot, maybe you can refer to it?
https://github.com/scgm0/Book-of-Genesis


text:
Document exporting nested subgroups

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

Thanks!

Thanks

to the reviewers

and the merger

too!

authors: Repiteo dalexeev


text:
MediaStream support?

I was wondering what the current state/progress is with MediaStream support? I'd like to help implement this if possible, primarily for voice chat, and would appreciate some pointers.

Came here also after starting to do some research on implementing voice chat in Godot. Sounds like WebRTCMediaSteamTrack would be a great addition, I created a proposal as you suggested @Faless
https://github.com/godotengine/godot-proposals/issues/813

Without a plain to support MediaStream, what's the purpose of implementing WebRTC in Godot?

My company would be happy to sponsor some work on this. We are offering $1500 bounty for this feature, https://gitcoin.co/issue/29615#
We will be putting up some other bounties for other video chat features in Godot. Feel free to get with if you want to get paid to build this out matt@projectlam.org

authors: Catchawink Wavesonics alexzheng mattkanwisher

repo: godotengine/webrtc-native


text:
Clean up and fix minor issues with default handling

Clean up and fix minor issues with default handling

Thanks @ReneWerner87 can you please do a v1.0.2 release when you have a chance?
thanks

https://github.com/gofiber/storage/releases/tag/coherence%2Fv1.0.2

repo: gofiber/storage


text:
Sweep: add JWT docs

Please generate detailed docs in code for the jwt.cpp and jwt.hpp files, including all the structs, methods, attributes etc.

💎 Sweep Pro: I'm using GPT-4. You have unlimited GPT-4 tickets. (tracking ID: None)

[!TIP]
I can email you when I complete this pull request if you set up your email here!

Actions (click)

[ ] ↻ Restart Sweep

I am currently looking into this ticket! I will update the progress of the ticket in this comment. I am currently searching through your code, looking for relevant snippets.

Step 1: 🔎 Searching
I'm searching for relevant snippets in your repository. If this is your first time using Sweep, I'm indexing your repository. You can monitor the progress using the progress dashboard

🎉 Latest improvements to Sweep:

New dashboard launched for real-time tracking of Sweep issues, covering all stages from search to coding.
Integration of OpenAI's latest Assistant API for more efficient and reliable code planning and editing, improving speed by 3x.
Use the GitHub issues extension for creating Sweep issues directly from your editor.

💡 To recreate the pull request edit the issue title or description.
Something wrong? Let us know.

repo: gofractally/psibase


text:
Some suggestions about conf file dir for Nix pm.

I am preparing gogs package to "functional" package manager NIX (nixos). There is an issue about custom conf. Hard fixed directory /etc/custom/conf makes some pain inside NIX pm.
Is it possible someway to set custom conf directory via env variable?

This is already possible (or at least - it works on my machine!). The GOGS_CUSTOM environment variable can be used to control the location.
I've got a set of debhelper scripts for packaging Gogs for Debian/Ubuntu - in my .deb package, I place my custom config file here: /etc/gogs/conf/app.ini then, in the service's unit file, I call gogs with: GOGS_CUSTOM=/etc/gogs set as an environment variable.

GOGS_CUSTOM is about only config or it influence other params?

I just did a test search of the repository. Looks like it also controls the expected location of 'robots.txt':

	...

	CustomPath = os.Getenv("GOGS_CUSTOM")
	if len(CustomPath) == 0 {
		CustomPath = workDir + "/custom"
	}

	if len(CustomConf) == 0 {
		CustomConf = CustomPath + "/conf/app.ini"
	}

	...

	HasRobotsTxt = com.IsFile(path.Join(CustomPath, "robots.txt"))

Thanks a lot.

authors: Losiara nrclark

repo: gogits/gogs


text:
install config 404 error

can't found the config page

tl;dr: fill the install form, click Install, disregard the « 404 » error because everything went fine anyway.
I followed the instructions for the Debian 8 package install, with gogs 0.8.25-1454711359.e797a22.jess amd64 using MySQL as backend.
First connection to gogs, got the install page ; fill the forms, hit the Install button, got a 404 not found image. I had to leave for some time, when I got back I hit Previous but somehow the session expired or something, so I tried to open the main URL (localhost:3000) to get back to the install process, but then, the expected UI appears, like the install process completed anyway.


text:
make windows colorable terminal

可以达到windows平台console日志输出colorable

Thanks your PR!
However, please read https://github.com/gogits/gogs/wiki/Contributing-Code#final-checks

Also, CI is failing...

authors: Unknwon eruca


text:
fix(deploy) fix kustomize controller image

fix #90

@bitsf
Please PR to 0.5.2 branch

authors: bitsf steven-zou

repo: goharbor/harbor-operator


text:
blogs' published date is displayed incorrectly in latest hugo version

Summary:
After upgrading to the latest Hugo version, the website's published date must be displayed correctly. Downgrading to Hugo 0.115.2 fixes the issue.
Reproduction Steps:

Using Hugo version 0.115.2, the publish date is displayed correctly (see screenshot 1).
Upgrade Hugo to the latest version.
The publish date is displayed incorrectly (see screenshot 2).
Downgrade Hugo to version 0.115.2 again.
The Publish date is displayed correctly again.

screenshot 1

screenshot 2

The fix is shown in this commit in my blog. I'm not sure what made this bug, but I hope my observation can be helpful.

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

$ hugo version
hugo v0.120.2-9c2b2414d231ec1bdaf3e3a030bf148a45c7aa17+extended darwin/arm64 BuildDate=2023-10-31T16:27:18Z VendorInfo=brew

Does this issue reproduce with the latest release?
Yes.

With v0.120.0 and later, the delimit function returns data type string instead of template.HTML, so you will have to pipe the output through the safeHTML function. The author of the PaperMod theme has aleady made this change:
https://github.com/adityatelange/hugo-PaperMod/commit/7795c90f6fa106733267481d9ed0518b00f2c62c

repo: gohugoio/hugo


text:
Hugo server not serving all/newly added content

I have just upgraded to Hugo 0.29 on macOS High Sierra; I have placed an image in public/img where my other images are kept, however, the images that I had previously placed in that folder are accessible at http://localhost:1313/img/image.jpg whereas the newly added image produces a 404.
The output from hugo server isn't really helpful, so I'm unable to provide any more details. All I can say is that I have then tried to serve the public folder from my local Apache server, and I noticed that the css and a few more folders (excluding the img folder) were missing. Upon running hugo again (just hugo), the folders have appeared, and serving the public folder via Apache works as expected.
I am willing to provide more details, but I will need some guidance as to how to obtain them.
Thank you.

Thanks for getting in touch, but it feels like this is a question  that would be better suited to the Hugo Discussion Forum.  We prefer to use GitHub issues only for bugs and enhancements. Feel free to update this issue with a link to the re-posted question (so that other people can find it) or add some more details if you feel this is a genuine bug. You may also find the answers you search for in Hugo Documentation.

@bep, Thanks for the feedback. I do feel like this is a bug since this functionality is not meeting the expected behaviour. I'd like to provide as many details as possible, however, I will need some guidance as to how to obtain it. If you still feel like this isn't a bug, please let me know and I will post this in the Discussion Forum as you suggested.
Thanks!

authors: bep finferflu


text:
Comment in first row of templates makes the page go blank

 (page is blank)
First row of layouts/blog/single.html
{{/*  TODO put images in blog folder  */}}

When I remove the comment, the page gets rendered.
URL of the page that disappears: http://localhost:8080/blog/article-name/
I am using _defaults/baseof.html, but this doesn't show either.
Or am i mistaken and it is a wanted feature?
What version of Hugo are you using (hugo version)?

Hugo Static Site Generator v0.63.2-934EE21F/extended linux/amd64 BuildDate: 2020-01-27T12:20:42Z

(via npm: hugo-bin)
Does this issue reproduce with the latest release?
Yes

This is still broken in 65.3:
Hugo Static Site Generator v0.65.3-211BA42A windows/amd64 BuildDate: 2020-02-23T09:58:40Z
a base template that starts with a comment results in 0 pages rendered.

authors: jstromergalley shiftgeist


text:
Split remote fecthing in resources.Get into its own function?

I'm sorry to bring this up so late, it did not occur to me before upgrading but I'm having second thought about this functionnality sharing its name with a very commonly used method.
Many people are using CMS, with markdown images added to the body content. We then try and improve generated images with render hooks.
This meant a simple with resources.Get .Destination to find the local image, and if not found use the existing .Destination. But with resources.Get going "remote capable", now any URL passed through resource.Get is a resource created and potentially processed by Hugo.
I envision several problems. A website publishing its image on imgix, and relying on the imgix server to transform image like https://xxxx.imgix.net/home_slide_kayak.jpg?auto=format&ch=Width,DPR&q=95&w=2000. The latter being accidentally passed through resource.Get would trigger an uneccessary fetch and transformation.
Not that many use case comes to mind beside render-hooks, and it's of course something we can "guard" by looking at the passed string and making sure it's relative.
But I'm opening a discussion here, in case other use cases could fall into the same problem. I do think, a bit late sorry again, that something as powerfull, could have its own name/method and its own entry in the documentation site, rather than share it with another commonly used one. It would also ensure that we have 100% control on what is locally "got" and/or "remotely" fetched.
We have

resources.Get
resources.GetMatch
resources.Match

Adding a fourth one, resources.Fetch or other wouldn't hurt.

Hmmm... resources.Fetch is not ... great, but I can live with resources.GetRemote (which was my second choice when I thought hard about this).
I'm doing another release later this week. I will let the Hugo community decide:

Voting for .GetRemote but dark-mode in Github breaks the voting images. Transparent is bad these days.

@davidsneighbour then turn off dark-mode,  not sure what you want me to do about it.

The latter being accidentally passed through resource.Get would trigger an uneccessary fetch and transformation.

@regisphilibert assuming you control the code, you can do
{{ if not (urls.Parse $url).IsRemote }}
{{ end }}

There are no accidents in the above?

And you would do something similar if you would use the new GetRemote func

Yes I would if the method was not renamed, but if it is renamed, then I'll stick with the original test (is there a local resource at the passed location?).
And yes, if I don't control the value passed to a .GetRemote, I'd safeguard it with your suggestion. That's helpful thanks!

Hmm ... The vote is clear.

This was bit like a trial, with the prosecution presenting evidence, and the jury voting to convict. I'm not sure the defense attorney was able to present their case.

@jmooring what did you vote?

.GetRemote and now I'm having second thoughts.

Yea, I'm still not sure ... One of Hugo's "problems" is a little too many moving parts. What I like about the Resource (which is a rather vague term in itself) thing is that is this rather simple interface that can be used for everything. And there is a a rather nice thing to also have only one way of getting these resources (there are more this this story, I know), especially when explaining it to the user (via documentation etc.).

... what about adding a resources.GetLocal function?

And there is a a rather nice thing to also have only one way of getting these resources (there are more this this story, I know), especially when explaining it to the user (via documentation etc.).

I'm focusing on the second part of that sentence. This functionality is extremely important as it makes Hugo capable of grabbing anything remote, (And yes API is what I'm mostly concerned about, and what I predict will make 80% of that feature's uses case), so let's make it stand out.
But also I think a function which grab a local file from the dedicated asset directory should not be the same as the one which give you access to the unlimited internet.

... what about adding a resources.GetLocal function?
That sounds like a big breaking change.

I've a big fan of readme-driven development, because it forces you to explain it to someone before you do it.
I have a docs PR in progress for content-management/image-processing/index.md...

Image Resource
To process an image, you must access the image as either a page resource or a global resource.
Image as Page Resource
A page resource is a file within a [page bundle]. A page bundle is a directory with an index.md or _index.md file at its root.
content/
└── posts/
    └── post-1/           <-- page bundle
        ├── index.md
        └── sunset.jpg    <-- page resource

To access an image as a page resource:
{{ $image := .Resources.GetMatch "sunset.jpg" }}

Image as Global Resource
A global resource is a file:

Within the assets directory, or
Within any directory [mounted] to the assets directory, or
Located on a remote server accessible via http or https

assets/
└── images/
    └── sunset.jpg    <-- global resource

To access a local image as a global resource:
{{ $image := resources.Get "images/sunset.jpg" }}

To access a remote image as a global resource:
{{ $image := resources.Get "https://gohugo.io/img/hugo-logo.png" }}

That sounds like a big breaking change.

Not from Hugo 0.90.

Not from Hugo 0.90 :-)
Why not?

Why not?

How would adding a new function be a breaking change?

@regisphilibert never mind, I was just blabbering; this was a rather breaking change when adding resources.Get -- I will add a GetRemote and get that out some time this weak.
@jmooring I can also add the adjustment we discussed re this, if you have not already implemented it...

authors: bep davidsneighbour jmooring regisphilibert


text:
tpl: Modify error messages of after, first, and last

Modified the messages functions after, first, and last threw on being passed invalid parameters (index or limit) to be more standardised and resemble what Go compiler would throw.
Fixes #6415

The change looks great, only one comment: We're a little pedantic about commit messages in this repo.
See https://github.com/gohugoio/hugo/blob/master/CONTRIBUTING.md#git-commit-message-guidelines
And I highly recommend reading this article: https://chris.beams.io/posts/git-commit/
Re. your commit message, I would change the title vs this:

each commit message should have a title/subject in imperative mood

I.e. "modified" > "modify" or something.

Is this better?

Yes.

Thanks a lot! :D

authors: BaibhaVatsa bep


text:
Merubah tujuan Link yang tadinya tidak bertujuan kemana-mana menjadi …

…link ke hacktoberfest

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


text:
New Theme: Hugo Bear Blog

Hi there 🙋🏼♂😁 (again)
Theme submission
Link to my theme repository: https://github.com/janraasch/hugo-bearblog
I made sure that...

[x] the repository contains a good README.md describing my theme
[x] an open-source license has been added to LICENSE.md
[x] all metadata have been added to theme.toml
[x] screenshots have been added in the images/ folder with the required dimensions
[x] in case I'm using a customized demo via the exampleSite folder that

[x] https://example.com is set as base url in exampleSite/config.{toml, yaml, json} to avoid the abuse of unused domains
[x] I tested that my theme's demo works with the content directory of gohugoio/HugoBasicExample

[x] I tested my theme against the gohugoio/HugoBasicExample

[x] I've checked the developer tools' console in my browser for error messages

[x] in case my theme is using Hugo Pipes features like toCSS and PostCSS that I have committed the /resources directory with all generated assets, for my theme to work in the basic version of Hugo

I don't have a Twitter-account, but I sure would not mind a mention of my website https://www.janraasch.com on Twitter :-).

Please let me know if you need anything else from my side.
Thank you ♥ and keep up the great work 👋.

Hi again 👋
thank you for creating new Hugo themes and for sharing them theme with the community. As always your theme should appear soon on Hugo's theme site and will be promoted on Hugo's official Twitter account.

Thank you very much, @digitalcraftsman.

authors: digitalcraftsman janraasch

repo: gohugoio/hugoThemes


text:
Refactor: swap to semver ranges for workspace packages

Move away from workspace:* for local workspace package dependencies. Reasoning is that we want a bit tighter control over what dependency is used for a package regardless where it is coming from. You could, for instance, creating a breaking semver change in a workspace package that is a dependency of another workspace package and inadvertently break that package or force yourself into making that one a breaking semver change as well.

Example:
For packages/predicates/package.json we would swap:
"@accelint/core": "workspace:*",

to
"@accelint/core": "^0.1.3",

@belsrc in theory yes, it should correctly bump the dependent package versions automagically

repo: gohypergiant/standard-toolkit


text:
ヂ is not handled correctly

The (rare) katakana 'ヂ' is not handled correctly in KanaToRomaji.
Test program:
package main

import (
    "fmt"

    "github.com/gojp/kana"
)

func main() {
	var test = "アイウエオダヂヅデド"
	fmt.Printf("Kana results: %s -> %s", test, kana.KanaToRomaji(test))
}

Output:
Kana results: アイウエオダヂヅデド -> aiueodaヂdudedo
Expected output:
Kana results: アイウエオダヂヅデド -> aiueodadidudedo
If you are interested, I can make a PR to fix it.

Thank you @akatsukle, I'd be more than happy to merge that PR if you make one.

Thanks for your prompt answer !
I took a deeper look, should we actually use the same transcription for both Katana and Hiragana unlike in my previous comment?
In which case, we would have:
ダヂヅ ->dajidu
While investigating, I also noticed that ヂャ, ヂョ, ヂュ were not handled either, adding them on the Hiragana model would give:
ヂャヂョヂュ ->jajoju
Note that they are actually used in Japanese in for instance ロヂャース
Finally, I also noticed that ヲ was not handled either, and actually contains オ instead in the conversation table. I suppose this to be a mistake and we should have:
ヲ ->wo
I've actually never seen that one outside of mangas, but since I was on it...
If you agree with me, then I'll proceed to add the test cases and to modify the table.

I took a deeper look, should we actually use the same transcription for both Katana and Hiragana unlike in my previous comment?
In which case, we would have:
ダヂヅ ->dajidu

Just to clarify, you mean ヂ => ji, rather than ヂ => di? That sounds good to me 👍

While investigating, I also noticed that ヂャ, ヂョ, ヂュ were not handled either, adding them on the Hiragana model would give:
ヂャヂョヂュ ->jajoju
Note that they are actually used in Japanese in for instance ロヂャース

Oh I see, it would be great if these were handled also.

Finally, I also noticed that ヲ was not handled either, and actually contains オ instead in the conversation table. I suppose this to be a mistake and we should have:
ヲ ->wo
I've actually never seen that one outside of mangas, but since I was on it...

That definitely seems wrong to me, as you said it should be ヲ. If you are able to, please feel free to fix that one as well :)
Thanks a lot!

Just to clarify, you mean ヂ => ji, rather than ヂ => di? That sounds good to me 👍

Yes exactly.

Did you mean "Katakana model" rather than "Hiragana model" though?

Yes sorry for being unclear. I just meant "using the same transcription on katakana that we're already using on hiragana"
I'll open a PR later today then, thank you.

authors: akatsukle shawnps

repo: gojp/kana

license: mit

license_source: bigquery


text:
Building with "go build"

So, if I want to build this (in Linux), how exactly should I make things work if I get this:
./main.go:48: undefined: nk.NkGLFW3Init
./main.go:48: undefined: nk.GLFW3InstallCallbacks
./main.go:51: undefined: nk.NkGLFW3FontStashBegin
./main.go:53: undefined: nk.NkGLFW3FontStashEnd
./main.go:72: undefined: nk.NkGLFW3Shutdown
./main.go:89: undefined: nk.NkGLFW3NewFrame
./main.go:138: undefined: nk.NkGLFW3Render
when running "go build" from the nk-example folder. Or, if I structure things "the Go way" in src folder.
$ go get github.com/golang-ui/nuklear/cmd/nk-example
$ nk-example
works fine. But I'm trying to set things up so I can build "the normal way", but I get the above annoyance. I do have the nk.go file in $GOPATH/src/github.com/golang-ui/nuklear/nk/ folder, and the nk.a file, but it's not found anyway for some reason... What am I missing here?

Hi @Chillance, sorry for inconvenience but yesterday I renamed the API methods because of new platforms added (not only GLFW). Has to do it.
nk.NkGLFW3Init -> nk.NkPlatformInit
nk.GLFW3InstallCallbacks -> nk.PlatformInstallCallbacks
nk.NkGLFW3FontStashBegin -> nk.NkFontStashBegin
nk.NkGLFW3FontStashEnd -> nk.NkFontStashEnd
nk.NkGLFW3Shutdown -> nk.NkPlatformShutdown
nk.NkGLFW3NewFrame -> nk.NkPlatformNewFrame
nk.NkGLFW3Render -> nk.NkPlatformRender

Current main.go from master from nk-example references all things right:
https://github.com/golang-ui/nuklear/blob/master/cmd/nk-example/main.go

Oh, ok. I did a pull, and now it all works. Thanks!

authors: Chillance xlab

repo: golang-ui/nuklear


text:
goimports doc lists out-of-date go-mode.el configuration

https://godoc.org/golang.org/x/tools/cmd/goimports
It says to add the following to .emacs:
(setq gofmt-command "goimports")
(add-to-list 'load-path "/home/you/somewhere/emacs/")
(require 'go-mode-autoloads)
(add-hook 'before-save-hook 'gofmt-before-save)

go-mode-autoloads is no longer used by go-mode (see https://github.com/dominikh/go-mode.el/issues/222), and this line will probably produce an error. That line should be removed.
Also, I found the add-to-list line confusing, because it's not clear from context whether this is optional or required. Might be good to remove that, and then say something like "This searches load-path for goimports, so you may need to add the goimports location to load-path." (Sorry for this separate issue. Feel free to tell me to break it out to a separate issue if it's too large or controversial.)

This issue tracker is for the gddo (godoc.org) project itself. You're referring to a package in the x/tools subrepo. People who work on goimports will not see it.
The right issue tracker is for the x/tools subrepo at https://golang.org/issues. You can see all the existing goimports issues at https://goissues.org/golang.org/x/tools/cmd/goimports.
Would you mind checking if the issue is already reported there, and if not, send it to that issue tracker? Thanks. I'll close this, because it's not a bug in gddo.

authors: phillipao shurcooL

repo: golang/gddo


text:
cmd/ld: if -s is given, pass to external linker

go version
go version devel +2420926 Wed Mar 25 02:55:56 2015 +0000 windows/amd64

go get -ldflags "-s" github.com/chai2010/protoc
# github.com/chai2010/protoc
panic: runtime error: index out of range

goroutine 1 [running]:
cmd/internal/ld.addpesymtable()
        C:/go/gotip/src/cmd/internal/ld/pe.go:1024 +0x46c
cmd/internal/ld.Asmbpe()
        C:/go/gotip/src/cmd/internal/ld/pe.go:1145 +0x167
main.asmb()
        C:/go/gotip/src/cmd/6l/asm.go:840 +0xde2
cmd/internal/ld.Ldmain()
        C:/go/gotip/src/cmd/internal/ld/pobj.go:207 +0x19a9
main.main()
        C:/go/gotip/src/cmd/6l/obj.go:44 +0x27

go version
go version go1.4.2 darwin/amd64

go build -ldflags "-s"
# github.com/chai2010/protoc
ld: warning: option -s is obsolete and being ignored
ld: internal error: atom not found in symbolIndex(__ZN6google8protobuf10TextFormat6Parser10ParserImpl11ReportErrorEiiRKNSt3__112basic_stringIcNS4_11char_traitsIcEENS4_9allocatorIcEEEE) for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
/usr/local/go/pkg/tool/darwin_amd64/6l: running clang++ failed: unsuccessful exit status 0x100

Even our misc/ccgo/test fails:
C:\>cd %GOROOT%\misc\cgo\test

C:\go\root\misc\cgo\test>go test -ldflags "-s"
# testmain
panic: runtime error: index out of range

goroutine 1 [running]:
cmd/internal/ld.addpesymtable()
        C:/go/root/src/cmd/internal/ld/pe.go:1024 +0x38a
cmd/internal/ld.Asmbpe()
        C:/go/root/src/cmd/internal/ld/pe.go:1145 +0x154
main.asmb()
        C:/go/root/src/cmd/8l/asm.go:728 +0xbec
cmd/internal/ld.Ldmain()
        C:/go/root/src/cmd/internal/ld/pobj.go:207 +0x14e0
main.main()
        C:/go/root/src/cmd/8l/obj.go:44 +0x23
FAIL    _/C_/go/root/misc/cgo/test [build failed]

Alex

The problem is that when -s is set, cmd/internal/ld will not generate the
COFF
symbol table, however, the symbol table is essential for external linking.
For now, please don't pass -ldflags -s if you're external linking, instead,
use
-ldflags "-extldflags -s".

It is Go linker crashing. It is bug that needs to be fixed.
I don't have computer to confirm, but I suspect it is crashing because we ncoffsym++ in initdynimport. Why do we ncoffsym++ if we don't store symbols into coffsym. ncoffsym will get reset to 0 later on anyway in addpesymtable. I think our logic is flawed.
Alex

It sounds like if -s is given but we find ourselves in external linking mode, then we need to remember the -s for invoking the external linker and not treat cmd/link as having the -s anymore.

authors: alexbrainman chai2010 minux rsc

repo: golang/go