text:
GDScript: Design goals

There are a lot of requests for changing stuff in GDScript, be it to extend functionality, make some syntax sugar, or add their favorite language feature. While it's good to know how people are using the language in order to improve it, deciding cases ad-hoc is prone to lead to inconsistency. It'll become more and more like a Frankenstein monster.
My proposal here is to create some master design goals for GDScript in the roadmap repository and decisions should be based on such document. That way there's a clear set of criteria to accept or reject proposals made by users.
This ticket is to ask about ideas on how to make such document, and what goals we should have in mind. This is not a place to ask for your wanted feature, this is more of "meta design", showing which way we should go in general, and not specific things that should go in and out of GDScript.
For instance, there are some decisions to be made:

GDScript should be kept as small as possible vs. embrace a large library of functions.
Whether it should have powerful operators that acts on different types, or it should be limited to mathematical concepts.
Add more Python-like statements, or go to a simpler route and add only what's hard/impossible to work around.
More functional vs. more procedural approach.
Only one way to do something vs. more shorthand constructs (AKA syntax sugar).
Whether to embrace a variety of coding styles and paradigms (being more welcome for experience from other languages) or define a more strict GDScript-way of doing things (being easier to collaborate with different coders).

And probably some other stuff that I'm forgetting.
The idea here is not to decide which features will go in (though that's the endpoint) but to make up which criteria we should use to decide the features.

These are some ideas that I gathered when I was writing a proposal for discussion. I'll leave them here as it is what I now have in mind:

GDScript should be expressive but not bloated.

E.g. we probably don’t need a list comprehension syntax, but there should be an easy way to do it, in particular for making nested Arrays.
In fact, this relates directly to the Godot API. The more things available in the API, the less GDScript needs to do (also, it’ll be available for other languages as well).

GDScript should try to be object-oriented, while allowing some functional paradigms.

This means that inheritance, polymorphism, encapsulation principles should be applied.
The language should provide first-class functions and implementation of common higher-order functions (such as map, filter, and reduce).
Re-use of functionality is also expected. So it needs constructs outside of inheritance to share code (such as Traits).

GDScript should be simple to write, hard to do wrong.

Type specifiers are optional, but types should be strong.
The compiler must try to catch as many potential errors as possible, showing error and warning messages (in debug mode) for possible programming mistakes.
The compiler should make code optimizations based on inferred semantics, even when the programmer is being verbose. E.g. treating a local variable as constant if it’s never changed.

GDScript implementation should be simple.

So more people can understand and contribute. We don’t really need a super optimized language, though we do want to have optimizations.
Syntax should be simple and fit an LL(k) grammar with a small ‘k’ value. I'm managing to assume LL(1) for the new parser, and so far it works. So I'm avoiding any syntax that increases lookahead (as this makes things harder to parse).
Reduce the number of builtin functions to a minimum (use the engine API for more things).

As a tutor the fact that GDscript is focused on gameplay programming at the moment is a great advantage. It does the job well yet it doesn't feel bloated and provided you're careful in how you implement things the code stays pretty easy to read.
I'd recommend to bring Lars Kokemohr in the loop: he's got a lot of gamedev experience, including AAA, thinks seriously about code architecture and languages, and he's got experience teaching Godot and Unity at university level so he's got great insights to offer.

GDScript should be kept as small as possible vs. embrace a large library of functions.

As small as possible is exactly the crux of the matter, because as possible implies as possible while still fullfilling its purpose.
Also, these are different concerns: a large library of functions does not necessarily imply a complex language. And this is exactly where I would try to draw the line:

Try to keep GDScript, the language, as small as possible
GDScript is hard to contribute to (and maintain), like the 3D renderer. Thus it scales badly with number of contributors. The larger and more complicated it becomes, the harder it is for others to improve upon it.
Favor performance and simplicity (and ease of use and learning) over features. We can add nice-to-haves, but should be conscious about the cost in terms of complexity.

Favor adding methods to the standard library over additions to GDScript
A large standard library scales way better than new operators or statements for GDScript.
This is why I was in favor of adding e.g. new String utility methods in the past:
In contrast to GDScript, these have no additional cost for us when making other changes; if I now add something somewhere else, I probably don't need to think about the implications of those String methods. But when we add things to GDScript, that influences every past and future contribution to GDScript, most of the time.

TL;DR:

Try to keep GDScript itself small, fast, easy to learn and maintain
Aim for a comprehensive standard library instead, Python batteries included style

Add more Python-like statements, or go to a simpler route and add only what's hard/impossible to work around.
Only one way to do something vs. more shorthand constructs (AKA syntax sugar).

There should only be one (exposed and documented) way to do a thing, but that way should be as easy as possible.

Whether to embrace a variety of coding styles and paradigms (being more welcome for experience from other languages) or define a more strict GDScript-way of doing things (being easier to collaborate with different coders).

Keep one Godot way to do things, like there is a Pythonic way to do things.
Don't make other styles impossible unless it gains performance/simplicity/ease of use, but don't encourage them officially either.

Agreed with @mhilbrunner here. Especially on the:

Keep one Godot way to do things, like there is a Pythonic way to do things.

Regarding the library part it means focusing on improving, adding nodes and other built-in classes right? Doing so benefits other languages too so it benefits every developer.

Please make these things more consistent:

The use of properties in lieu of getters and setters still leans heavily in favor of the latter.  Usage could be reflective of the expected amount of impact or side effects reading or changing a value has, but it's not always clear.

Constructor syntax is wildly inconsistent.  Some types have functions which return an instance of it's type as a special overload of it's type name.  Others use the .new() or .instance() syntax, types of which aren't clearly documented.  Yet others still use an initializer function with a void type on a recently created instance.  Arrays and dictionaries have their own unique syntax.
This all might be alleviated with function overload support, which may require better type hinting to implement, which brings me to...

More consistent type hinting.  Yes, gdscript is duck typed.  But hinting was clearly favored in some places early on and it would be helpful for users to have explicit syntax for it everywhere vars can be declared, not just in exports.  The syntax which already exists is already compatible with most use cases, save for explicit instancing because of the inconsistent ctor syntax.  Maybe it's my inexperience with dynamic typed languages leading to my confusion.  Can type-hinted exports can be Nil until explicitly initialized? Regular script variables seem to rely on determining its type at declaration based on assignment, and implicit type conversion behavior isn't yet clear to me.  Getting back to the point, making this behavior more obvious will help make it easier – or possible, if it isn't already – to unify the syntax used to give a recently declared variable a value.

Hopefully neither of these points ventured too far into feature request territory.  Some things seemed necessary to implement to meet these design suggestions as a matter of course, but may not be necessarily reflective of the major contributors' design goals for the language...

@homer666 Have to agree. Those were nice changes for sure.

I miss functional things a little, especially lambdas which were proposed 3 times now but for some reason never went merged... maybe not enough time to review / big updates were coming at the same time?
Also, I miss an await, or perhaps a better yield. When you deal with timed things such as requests or even dialogs, using callbacks all over the place gets messy really quick (since all vars need to be flattened as class members and you get more functions in the same scope).

I mostly agree with @vnen. This is more a practical than a theoretical thing:
GDScript codebase needs to stay small to be maintainable. The more features we add, the more unmaintainable it becomes. Features that you may use only a few times in your project that will save 2 or 3 lines of code, should not be included.
If adding a cool feature that will be useful a few times only takes like, 1 or 2 lines of code.. this is fine, nothing against it. If adding it takes several dozen lines of code, then it will most likely be rejected.
Property access and the $ operator were features you use often that definitely improve quality of life. The upcoming optional typing is the same.. so even if they need a few dozen lines of code, they are worth it.
Lambdas may also be useful, but if it means hugely increasing GDScript size, then they should not be added.
The best approach that needs to be taken here to implement features is to do it using the least amount of new code possible.

I think it should track python as closely as possible.

Disagree, Python is a different language with way different goals.
Take the ideas that fit and sure, let GDScript be inspired by it, but don't cling to it too hard.
But yeah, lambdas/first class functions and variable amount of arguments for functions (variadic functions) are the two biggest things I miss, Zylann. :P Sorry, thats kind of "feature wishlist" territory again.
Again: Happy birthday, @reduz :)

This is great in theory, but in practice it makes the codebase more difficult to maintain. I think the fact Python will soon be an optional language will be a solution for developers who really can't live without the more advanced syntax sugar.

Exactly what I meant.
Also.. Happy birthday :)

Keep one Godot way to do things, like there is a Pythonic way to do things.
Reminds me of something I was working with yesterday. When we want the size of an Array, do I use array.size() or len(array). When I want to append to the end of an array, do I array.append(item) or array.push_back(item).

Personally I prefer using array.size(). It's more consistent, just a method call like any other. While len(array) seems to be some kind of special language construct that AFAICT exists only to mimic Python.
And similarly with array.push_back(item). There's already a push_front() method so it seems more consistent.
Of course these are very specific examples, but I just wanted to highlight something worth considering.

Thanks for all the responses.
First, let me clarify a few points that seem to stir confusion:

There are 3 different syntax for constructors.

Not really. One are for primitive types, which are not "instances" per se (like Color()). One you create a new instance of an object (Object.new()). The other one is not a constructor, it is meant to get the scene out of a PackedScene resource ( scene.instance(), which is just a regular method from PackedScene).

Array.append() and Array.push_back() do the same thing.

This is more about how you can use the array as queue, list, or stack using more conventional function names. But this should be another discussion since they are not GDScript constructs, they are part of the Godot API. There's an important difference there, because changing this API requires no change to GDScript itself.

The choices aren't mutually exclusive.

My list was more about examples for discussion than strict decisions to make. Many of those can be viewed as a spectrum rather than a discrete boolean choice.

I miss X from my experience with other languages.

That's quite a complicated topic and it relates to my last bullet from the OP. The thing is that while you might want to do it in the way you're used to, there might be another (more Godot-y) way to do the same thing. Hence my question: should we embrace many paradigms or solve this by documenting the translation between those and the Godot way? For instance, signals are very important in Godot but many people seem to forget they exist.

About the len() function.

This is a GDScript function but it serves more to generalize getting the length of different types of collections (for instance, Array.size() vs. String.length()). Though this might only be solving a deficiency in the API itself, which can be discussed. This might apply to a few other built-in function as well.

From what I can gather from this discussion (and the previous history) so far:

People are not so fond of syntax sugar, but a few constructs are really wanted.
Preference seems to be a small but expressive language.
Less ways to do the same stuff are better and that way should be simple.
Add stuff to the main Godot API instead of a new constructs/functions in GDScript. I just want to note that adding to the API has its own criteria.
There are still sorely missed features in GDScript that make it not expressive enough (variadic functions/splat operator, first-class functions/lambdas, null coalescing operator, and maybe a few others).

Also, while I do like embracing the functional paradigm, if we add first-class functions we'll probably need more functional stuff as well (such as map() and reduce() for collections, currying/partial application). And that will affect that typing system that's on the way (type hints might include not only that it is a "function" but the signature as well). This is something to consider.

I have a recommendation and that is to look for some metric of improvement(e.g. ratio of LOC added in GdScript to LOC saved in example scripts). This is a technique I have read that Niklaus Wirth used in his languages, with the main metric in his case being the speed with which the compiler could compile itself. This led to tradeoffs between source code size and algorithmic optimizations, with simpler, cleaner  algorithms often winning out when put to the test.
Doing this will help in rejecting bloat going forward, while still allowing for some evolution. Features that eliminate whole classes of errors in user code would override a rule like this(maybe there is a way to capture potential error rate in a number?)

IMHO LOC is a bad metric. It only measures volume, not quality. It doesn't capture whether the example code improves, or becomes more readable and maintainable.
Shorter code isn't necessarily better. See arguments about better variables names.

I assume LOC was only an example of metric, not an actual proposal. The idea of a metric is interesting, but I can't think of anything that would fit nicely into "the Godot way" of doing things.

This is probably controversial, but in my opinion I think that moving towards reactive (not necessarily functional, although it kinda' comes with the territory) is what needs to happen. For multiple reasons, but most of all it's just natural to work with when dealing with time and multimedia interactions. It's the response to contemporary needs and most languages are moving in this direction, mostly through libraries, but there are a few that have built-in functionality (like dart). For generic info on reactive programming and why it's so useful check this.
This imperative type of programming is suited very well for input -> crunch -> output type of applications, not interactive stuff.
Think of the mouse, instead of getting one value at a time (through connecting to the event) and being forced to keep track of the time yourself and do maths with time, control flow etc. is very unnatural. Instead, with composable streams where you have "atomic" functions that operate on incoming data as data is fed into the pipe is far more natural, it's exactly what you'd expect to do, instead of keeping track of each individual event and having to think about all the interactions with future/past events, keeping track of them individually, a stream that takes say for example the events in the last 0.5 sec and gives them to you to process or combine multiple streams or just give you double taps as an event are much more natural.
So I do agree with everyone before me about keeping it simple and maintainable, I just don't think that sticking with the imperative style is suited for interactive applications. It can be done sure but with a lot of boilerplate and it's very easy to get wrong the order in which you process stuff as things get passed around all over the place randomly really, if you think about the user interaction with the game.

There has been a lot of discussion so far, and from what I gather it seems that we've been able to narrow down on some design goals for GDScript. Is there more to discuss, or is this ready to be concretized in the form of some docs in the roadmap repo, as originally mentioned?
For what it's worth, I agree with a lot of what has already been mentioned, including the summary in https://github.com/godotengine/godot/issues/18698#issuecomment-388073116. I would suggest, though, adding "consistency" (both in APIs as well as in GDScript itself) as a goal in addition to the ones you already listed.
Rationale:
Consistency in syntax and naming decreases cognitive load and allows developers to build more of an intuition around how the system works. In some cases, it may be justifiable to break consistency in order to (for example) highlight a truly unique case or make slow / "dangerous" operations easier to detect - but in the general case, I think we should strive for consistency.
For example, as mentioned, the 3 different syntaxes for "constructors" apply to different cases / types of entities, but we should consider whether the differences are important enough to justify different syntax. As a developer using Godot, do I really need to care that Color is primitive and Object isn't, such that I have to do Color() vs Object.new()? If there is a good reason for the developer to care, then perhaps the different syntax is justified - but otherwise, they would ideally be made more consistent.

In terms of future elements that godot could have, a short hand for funcref() might be a useful way to provide some kind of functional support without having to support lambdas immediately. I'm thinking of something similar to the way that $ works, maybe using an -> syntax. For instance:
self->gotoscene

Would basically be the equivalent of writing something like....
funcref( self, "gotoscene" )

Idk how others would feel about this, but it could be kind of useful...

I don't think it's worth adding a special operator just to shorten funcref, the latter is already quite short to write. I'd prefer actual lambda support. At best, for a shortcut, the syntax object.method without () could be a better step towards first-class functions.

What do the discussions in this thread mean for issues such as #23101? Would such complex things ever be added if they are only useful in some situations for some users?

@aaronfranke this comment is quite relevant regarding typed GDScript https://github.com/godotengine/godot/issues/23101#issuecomment-430833465

Adding this to the OP as well for visibility, but these are my current ideas:

GDScript should be expressive but not bloated.

E.g. we probably don’t need a list comprehension syntax, but there should be an easy way to do it, in particular for making nested Arrays.
In fact, this relates directly to the Godot API. The more things available in the API, the less GDScript needs to do (also, it’ll be available for other languages as well).

GDScript should try to be object-oriented, while allowing some functional paradigms.

This means that inheritance, polymorphism, encapsulation principles should be applied.
The language should provide first-class functions and implementation of common higher-order functions (such as map, filter, and reduce).
Re-use of functionality is also expected. So it needs constructs outside of inheritance to share code (such as Traits).

GDScript should be simple to write, hard to do wrong.

Type specifiers are optional, but types should be strong.
The compiler must try to catch as many potential errors as possible, showing error and warning messages (in debug mode) for possible programming mistakes.
The compiler should make code optimizations based on inferred semantics, even when the programmer is being verbose. E.g. treating a local variable as constant if it’s never changed.

GDScript implementation should be simple.

So more people can understand and contribute. We don’t really need a super optimized language, though we do want to have optimizations.
Syntax should be simple and fit an LL(k) grammar with a small ‘k’ value. I'm managing to assume LL(1) for the new parser, and so far it works. So I'm avoiding any syntax that increases lookahead (as this makes things harder to parse).
Reduce the number of builtin functions to a minimum (use the engine API for more things).

@vnen E.g. treating a local variable as constant if it’s never changed.

This reminds me, it would be really nice to have local const fields. They would be forcefully unchangeable like class-level constants are, but limited to the scope they're declared in.
I agree with all your points, but I'm a bit confused as to what "LL(k)" means. Does LL(1) mean that any given token's behavior is not changed by the following token? That sounds good to me.

I second @aaronfranke on local constants. In some longer files we've worked on lately, we had quite a few cases where we needed just that (specific tween-based animations with different durations and delays, among other things)

@aaronfranke There's a proposal about immutable variables here: https://github.com/godotengine/godot-proposals/issues/820

@aaronfranke

This reminds me, it would be really nice to have local const fields. They would be forcefully unchangeable like class-level constants are, but limited to the scope they're declared in.

I'm already doing this in the GDScript rewrite.

[...] I'm a bit confused as to what "LL(k)" means. Does LL(1) mean that any given token's behavior is not changed by the following token? That sounds good to me.

That's indeed a quite technical term. One L means that it parses left-to-right, the other means "lookahead", and k is the amount of tokens of lookahead need to decide the grammar production (e.g. whether it's a variable or function declaration or something else). LL(1) means the parser needs to look at the next 1 token to decide which function to run. A larger number means it has to buffer more tokens and have more possibilities to decide the next function.
Note: It is possible to have an LL(0) language, which is super simple to parse, but it's very difficult to make it look natural and useful.

Be newbie friendly.
It already is and should stay that way while becoming even friendlier.
So for example i'd like it to avoid confusing syntax like { = }
var s = "foo"
var d = { s = 5 }
var f = { s : 5 }

Newbie can be unaware of optionally skippable quotes. Or s/he could not notice there's = and not : (or vice versa).
Or here - newbie can think $ is fetching a node named bar:
	var foo = "bar"
	$foo

I'd like to point out an other area of focus that is rarely actually talked about which is productivity. Having a hammer which is easy to learn how to use, or easy to construct/repair for the manufacturer is all well and good, but the hammer exists to be used to achieve some result. A hammer which is more difficult to learn, or harder to make, is absolutely worth it if it produces better results.
The point of scripting languages is not really to be easy to learn but instead to be easy to work with in order to get high productivity. (This is also what makes them easy to learn.) You want to be able to quickly write only a small amount of code and get your idea working. Compiled languages instead focus on runtime performance.
Python is the epitome of productive languages and GDScript is inspired by it because it shares the same strong focus on productivity, with the desire to be able to quickly write game logic and mechanics. It is important to remember this when considering what features to add.
It's true that maintaining all of the features of Python in GDScript would certainly be too much work, and some things wouldn't even fit at all because of performance since game code often needs to run every single frame. It is, however, not true that Python is difficult to learn - despite all those features. This is because you don't have to use features you don't know.
With this in mind
I certainly agree on having a large standard library, since it increases productivity. Also, as has been pointed out, it doesn't make the language itself more complex so it doesn't add much to maintenance. The requirement for inclusion should be very low - even if it only helps a few only a little.
For instance, Array.extend and Dictionary.update. Making those functions yourself is only 4 lines of code each and most people don't need them most of the time. But including them costs nothing and it increases productivity. I'm guessing there'd also be quite a difference in performance. An other example is a lack of a simple builtin function for listing a directory. Python is full of functions like these and GDScript should be too.
On the subject of list comprehension (with dictionaries too); I know some people really don't like them, and that's fine - you don't have to use them - but they're very productive if you're comfortable with them. Also, generators/iterators from yield in functions and array-slicing syntax. And sets. And itertools etc. Often you're only working with individual things but as soon as you have a bunch of something all of these functions and features become very useful. It's true that they can be hard to wrap your head around for beginners, and I don't know how much those features would affect the parser, but they're just so productivity once you learn them.
Keyword arguments (optional unordered arguments with defaults) is an other example of an extremely productive feature, even for beginners. It almost doesn't matter what the implementation cost is, because it makes it so easy to create objects and call functions with only the arguments you want. With it you can have all the .new() of nodes etc accept the three parameters you want to change right away instead of having them on three extra lines afterwards.
Then there are things like custom datatypes (for overloading operators). Beginners won't use them, that's fine. But in some situations it makes all the other code so much easier to work with, greatly increasing productivity. This feature has performance implications for other code, even when not used, but I think it can be implemented separated from the normal object.
Again these are just examples, but I think productivity should absolutely be a core part of the design goals. GDScript exists to get more work done faster.

Newbie can be unaware of optionally skippable quotes. Or s/he could not notice there's = and not : (or vice versa).

Honestly a newbie will be unaware of many things, because they are a newbie. Such person should be reading documentation and tutorials to learn. The GDScript basics page is not that long (sure, it has a lot to soak in, but such mistakes can be avoided and understood by reading the relevant section again). That's not an excuse to bloat GDScript but we should not strip it and remove features from the pros to write optimal code just because a newbie might stumble on it.
BTW the { a = 1 }  syntax is based on the Lua tables, which is supposed to be a basic language. It helps writing dictionaries when every key is a string.

I certainly agree on having a large standard library, since it increases productivity. Also, as has been pointed out, it doesn't make the language itself more complex so it doesn't add much to maintenance. The requirement for inclusion should be very low - even if it only helps a few only a little.

Note that adding things to Godot should follow the proposal workflow. And if something is not used often it won't make the cut. The point is that those things do not need to be provided out of the box from Godot but instead provided as plugins that you can download from the Asset Library. So only those who need it will get it.

For instance, Array.extend and Dictionary.update. Making those functions yourself is only 4 lines of code each and most people don't need them most of the time. But including them costs nothing and it increases productivity. I'm guessing there'd also be quite a difference in performance. An other example is a lack of a simple builtin function for listing a directory. Python is full of functions like these and GDScript should be too.

Well, it costs almost nothing to add one thing. But then one by one this becomes a lot of things, and then it does make a difference. How often you need to list a directory in a game project? If you need to process the entries, iterating a Directory object won't be much different than iterating a list you got with a builtin function. Also is it recursive or not? Should it show hidden (dot) files? As you start adding arguments to customize that, the function isn't so simple anymore (and if you don't add those then it's less useful thus less used). It's not that simple to add stuff without thinking of use cases, that's why we introduced the proposals.

Keyword arguments (optional unordered arguments with defaults) is an other example of an extremtely productive feature, even for beginners. It almost doesn't matter what the implementation cost is, because it makes it so easy to create objects and call functions with only the arguments you want.

Adding keyword arguments would make the release binary bigger and it would introduce a performance cost every time you use them. You know what's gonna happen? It will get a bad rap for the performance penalty and people will start recommending not using it, which renders the feature pointless.

Again these are just examples, but I think productivity should absolutely be a core part of the design goals. GDScript exists to get more work done faster.

My point is that GDScript should be easy to write, which kind of implies that we want people to be productive with it. But it should not happen in detriment of other points. Even though performance is not the goal above it all, we should not make it slow for an edge-case feature.
And again: everybody can open a proposal for a particular feature they need. My ideal for this "design goals" is to be one parameter for the GDScript-related proposals to be considered (notice that I opened this issue way before the proposal system was in place). It's mostly guidelines that are a tad subjective. So most of the examples could actually be added, as long as they go through the workflow we set up. This is not a dismissal for the examples, just an explanation that it's not that simple to "just add everything that is marginally helpful" as that could have an impact in other areas even for people who don't use it.

Closing, as GDScript 2.0 is now feature-complete. Further changes should be discussed on the Godot proposals repository.

authors: Calinou NathanLovato TheYokai Zylann aaronfranke hilfazer lorenzobeccaro mhilbrunner mwerezak nobuyukinyuu razvanc-r reduz triplefox vnen voithos xix-xeaon


text:
Array.custom_sort() not giving expect results.

Win10 64-bit alpha 3.1 115885b
I have an array of vectors that I would like to sort by X component first, then sub sort the Y component.  This current code doesn't seem to work.  Am I missing something, or is this an instability issue on the back end?
extends Node2D

var array = []

func sort(a, b):
	return a.x < b.x and a.y < b.y # Is this not correct?

func _ready():

	array.append(Vector2(2, 2))
	array.append(Vector2(2, 1))
	array.append(Vector2(1, 1))

	array.sort_custom(self, "sort")
	print(array)

I have an array as [(2,2), (2,1), (1,1)], and trying to get it to sort into [(1,1), (2,1), (2,2)], however I get the following:

Example Project:
3.1 Custom Sort Issue.zip

Given a = (2, 1), b = (2, 2)
a.x < b.x and a.y < b.y
 (2 < 2)  and  (1 < 2)
     true and false
         false

False means a > b thus a is placed after b.
You need
if a.x < b.x:
    return true
else:
    return a.y < b.y

Thanks Naryosha, that is the solution, you beat me to it.
Was a late night logic error on my part.  I slept a couple hours and woke up with this thought, "It should check for equals first..."
Wrote this version and came back to close this before someone discovered.  XD
static func point_sort(a, b):

	if(Lib.nearly_equal(a.point.x, b.point.x)):
		return a.point.y < b.point.y

	return a.point.x < b.point.x

source: gharchive/issue

authors: Naryosha avencherus

repo: godotengine/godot

license: MIT

license_type: permissive

license_source: github-api


text:
Opening a scene should focus on the root node

Godot version:
629ac20a
Issue description:
When opening a scene in the editor, no node is focused. I believe the root node og the scene should be focused by default.
My use case: I have different levels with different configuration parameters that are export vars of the root of the level. After adding an export var, I wanted to double check that I assigned it properly everywhere (default does not apply here). This made me click once for every scene on the root node.
If the root node was automatically focused, i wouldn't have had to click for every scene that i opened.

When you open a project it's not focused on root node - look at picture. If I close and open scene again - it works like expected.

@akien-mga is my pr already merged in beta4?

Yeah, see the changes between beta3 and beta4: https://github.com/godotengine/godot/compare/a8510331c0115eeee2d6ac0a4acbeb5d4df833b3...17809ca9a907b8d48bea2fd26ea42312a9eaaca4

Thanks @akien-mga !
Can confirm on latest master. I will need to investigate. Thanks @breakmt for the report!

Maybe we should re-open this? I'm not sure how it is usually done, but I'm afraid you can forget about this bug :)

It would be better to open a new issue for the remaining bug. This bug was fixed, opening a scene does focus the root node. What's not working is focusing the root node of the main scene when opening the editor itself.

done #26006

authors: QbieShay akien-mga breakmt


text:
Unable to make CollisionPolygon2D from specific array

**Godot version:3.1

OS/device including version:

Issue description:

the follow array can not make a valid CollisionPolygon2D. However, it's a valid array to make a Polygon2D.
[(0, 805), (60, 773.250732), (120, 688.083008), (180, 576.537048), (240, 474.027863), (300, 413.10141), (360, 413.10141), (420, 474.027863), (480, 576.537048), (540, 688.083008), (600, 773.250732), (660, 805), (660, 805), (720, 773.250732), (780, 688.083008), (840, 576.537048), (900, 474.027863), (960, 413.10141), (1020, 413.10141), (1080, 474.027863), (1140, 576.537048), (1200, 688.083008), (1260, 773.250732), (1320, 805), (1320, 805), (1380, 773.250732), (1440, 688.083008), (1500, 576.537048), (1560, 474.027863), (1620, 413.10141), (1680, 413.10141), (1740, 474.027863), (1800, 576.537048), (1860, 688.083008), (1920, 773.250732), (1980, 805), (1980, 1080), (0, 1080)]
Steps to reproduce:
1.add a new StaticBody2D
2.add a CollisionPolygon2D to the StaticBody2D
3.set the polygon to the value as above values.
Minimal reproduction project:

Could you provide a test project that reproduces it? And a screenshot of the polygon?

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

Two points are appearing twice:
(660, 805), (660, 805)

and
(1320, 805), (1320, 805)

If duplicates are removed, the collision polygon works correctly. So maybe not a bug?

I checked this and indeed removing these points fixes the issue, otherwise we get "Convex decomposing failed!" error. It would be perfect if it told what exactly is wrong, but not sure if it's possible.
That would be enough to close the issue, but then I tried randomly duplicating different points and seems like not every duplicate point will make the polygon fail. So there is some inconsistency here.

What would be the correct behavior internally?

Ignore duplicate points in collision generation.
Print an error message stating there are duplicate points, and asking the user to fix their input as it's not valid.

authors: Calinou KoBeWi Zylann akien-mga alexzheng


text:
StyleBoxTexture axis stretch tile and tilefit doesn't work when using GLES2

Godot version:
v3.1.2
OS/device including version:
Windows 10 pro education 64 bit
Issue description:
styles that use tile or tilefit as their axis stretch just stretch it and don't actully tile it.

Steps to reproduce:

make new theme
create the hscrollbar templates
make the hscrollbar scroll style use a tile streach mode for both axes
back out to theme editor and see it still stretches and doesn't tile at all

Minimal reproduction project:
GUITest.zip

3.2.2 stable, still a thing.

Can still reproduce on v3.5.2.stable.official [170ba337a]

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


text:
Keys not working if Ctrl+Alt is needed

Godot version
v3.2.1.stable.mono.official
OS and device
Windows 10 on MSI gf62 8rd
Issue description:
The keys that need to be typed by using Ctrl + Alt do not get recognized by Godot. They get picked up by other programs though. I believe it is caused because those keys need Ctrl & Alt to be pressed to register, as I have tested with the On-screen-keyboard and I still have that problem. In my case it is a big problem because in my country's keyboard layout the curly and square brackets among other keys need that combination.
Steps to reproduce:
Can be reproduced by creating a script and trying to write a character that needs the said combination
Minimal reproduction project:
None. The issue can be recreated in any project.

What is your keyboard layout? I can test this and see if I can find the problem

Duplicate of #6851


text:
Popupmenu reopened instead of closed when the popup button is clicked

Godot version:
Commit 0f1da724924fc494bfd316c57757e0e1d7b90143
OS/device including version:
OS: Windows 10
GPU: Intel Iris
backend: Vulkan
Issue description:
When I open a popup menu on an inspector, then click the popup menu button again, the popup menu is reopened instead of closed.
I see that in Godot 3.2, both the selected value and the downward chevron are integrated into a single dropdown button, but Godot 4.0 is separating them into a dropdown button and a dropdown trigger (selected value).
Steps to reproduce:

Create an Environment node.
Click on the Environment popup button on the node's inspector to open a popup menu.

Click on the popup button again. The popup menu is closed and then reopen, instead of being closed.

Minimal reproduction project:
This is reproducible in any project.

I would like to try to make a contribution. However, Godot code base pretty big. I would appreciate some guidance 😄
Hope all is contained in popup_menu.h

That's how it was working before - 3.2 has the same mechanics when clicking on that arrow? Should it be really altered, what's the benefit in here?

It is fixed by #38340

It's a bug, because the MenuButton doesn't respect the visibility when opening the Popup

That's how it was working before - 3.2 has the same mechanics when clicking on that arrow. Should it be really altered, what's the benefit in here?

If I opened a dropdown, then decided to not change the value, then instead of just simply click the button again without having to move the cursor, I would have to move the cursor somewhere and click the mouse to close the menu. Well, I can just press Esc, but that's more like a workaround .

Well turns out I actually broke the button completly. I thought, it's the same button. I have to check that... But I have to touch the PR again anyway

@HaSa1002 I've tried to understand the codebase and failed to comprehend them. 😆 Guess, I need more time and stronger C++.

Go for an easy reproducible issue and follow the red line of the callstack. That's the easiest way of finding out what matters. You find the entry point in the platform, btw

This appears to be fixed as of 4.0.beta4. Here, I'm single-clicking to open and close the popup at first, then double-clicking to open and close:
https://user-images.githubusercontent.com/180032/200910707-be3b6780-2cb4-4ae2-9c88-50a750e732f4.mp4

authors: Calinou HaSa1002 dreamsComeTrue varshard


text:
C# Wrong Script attached in PackedScene when using Constructor to "build" Node in another Class

Godot version:

3.2.2 Mono
OS/device including version:

Linux 5.7.10-arch1-1
Mono JIT compiler version 6.10.0
Issue description:

When you build a Node in another Class, and than pack it as .tscn File, it attaches a wrong Script resource:
script = SubResource( 1 )
Steps to reproduce:
using Godot;
using System;

public class MainScene : Node
{
    public override void _Ready()
    {
        Node node = new Node();
        Sun sun = new Sun();
        node.AddChild(sun);

        sun.Owner = node;

        PackedScene packedScene = new PackedScene();
        Error error = packedScene.Pack(node);
        GD.Print(error);
        error = ResourceSaver.Save("res://NewMainScene.tscn", packedScene);
        GD.Print(error);
    }
}

using Godot;
using System;

public class Sun : DirectionalLight
{
    public Sun()
    {
        ShadowEnabled = true;
        RotationDegrees = new Vector3(-45, 180, 0);
    }
}

This then is the generated tscn File:
[gd_scene load_steps=2 format=2]

[sub_resource type="CSharpScript" id=1]

[node name="" type="Node"]

[node name="@@2" type="DirectionalLight" parent="."]
transform = Transform( -1, 6.18172e-08, -6.18172e-08, 0, 0.707107, 0.707107, 8.74228e-08, 0.707107, -0.707107, 0, 0, 0 )
shadow_enabled = true
script = SubResource( 1 )

Minimal reproduction project:

Test.zip

Related to #10189.

As I understand it, this issue seems to be the same as https://github.com/godotengine/godot/issues/48828 so I'll close it as duplicate since the other one has more information.

authors: JupiterRider akien-mga raulsntos


text:
Crash on startup

Godot version: master (cba3b024b5)
OS/device including version:

macOS 11.2.3
Intel Iris Graphics 6100 1536 MB

Issue description:
Godot crashes every time I start it (both project manager and editor).
Here is the backtrace:
arguments
0: bin/godot.osx.tools.64s
Current path: /Users/timothy/repos/godot
Godot Engine v4.0.dev.custom_build.cba3b024b - https://godotengine.org
Vulkan API 1.2.162
Using Vulkan Device #0: INTEL - Intel(R) Iris(TM) Graphics 6100
handle_crash: Program crashed with signal 11
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[1] 1   libsystem_platform.dylib            0x00007fff20427d7d _sigtramp + 29
[2] 2   ???                                 0x000062600000eba8 0x0 + 108164456442792
[3] vkGetPhysicalDeviceProperties2 (in godot.osx.tools.64s) (trampoline.c:2262)
[4] VulkanContext::_check_capabilities() (in godot.osx.tools.64s) (vulkan_context.cpp:514)
[5] VulkanContext::_create_physical_device() (in godot.osx.tools.64s) (vulkan_context.cpp:857)
[6] VulkanContext::initialize() (in godot.osx.tools.64s) (vulkan_context.cpp:1510)
[7] DisplayServerOSX::DisplayServerOSX(String const&, DisplayServer::WindowMode, unsigned int, Vector2i const&, Error&) (in godot.osx.tools.64s) (display_server_osx.mm:3855)
[8] DisplayServerOSX::DisplayServerOSX(String const&, DisplayServer::WindowMode, unsigned int, Vector2i const&, Error&) (in godot.osx.tools.64s) (display_server_osx.mm:3891)
[9] DisplayServerOSX::create_func(String const&, DisplayServer::WindowMode, unsigned int, Vector2i const&, Error&) (in godot.osx.tools.64s) (display_server_osx.mm:3577)
[10] DisplayServer::create(int, String const&, DisplayServer::WindowMode, unsigned int, Vector2i const&, Error&) (in godot.osx.tools.64s) (display_server.cpp:613)
[11] Main::setup2(unsigned long long) (in godot.osx.tools.64s) (main.cpp:1526)
[12] Main::setup(char const*, int, char**, bool) (in godot.osx.tools.64s) (main.cpp:1387)
[13] main (in godot.osx.tools.64s) (godot_main_osx.mm:72)
[14] 14  libdyld.dylib                       0x00007fff203fe621 start + 1
[15] 15  ???                                 0x0000000000000001 0x0 + 1
-- END OF BACKTRACE --
Abort trap: 6

Debugger shows null pointer access in loader.c at line 8303, the fpGetPhysicalDeviceFeatures2 is null.
https://github.com/godotengine/godot/blob/cba3b024b5d08b79e4389dc2c374e38ab4a64ff9/thirdparty/vulkan/loader/loader.c#L8301-L8304
This crash happens since #47250 is merged.
May be related: https://github.com/KhronosGroup/Vulkan-Loader/issues/51
Steps to reproduce: It crashes every time I run godot.
Minimal reproduction project: N/A

Sorry, just came across #47715 and the crash stops after I updated the Vulkan SDK.


text:
Overridden Functions Not Called if Invoked from a Typed Variable

Godot version
v4.0.dev.calinou.de83ee57e
System information
Windows 10 x64
Issue description
Let's say you want to override a built-in function like queue_free(). That's easy and straightforward and normally when you call object.queue_free() the overridden implementation takes precedent.
But if object is a typed variable reference and it's typed to something higher up in the hierarchy than your overridden implementation (or so I speculate), then the custom implementation is not called.
Steps to reproduce
Have some object override queue_free(). Make a variable reference to it that is typed (var typed_reference : Node = $Path). Call typed_reference.queue_free() and notice that the custom code you wrote was ignored.
Meanwhile if you reference was var untyped_reference = $Path then calling untyped_reference.queue_free() would have the expected behavior.
Minimal reproduction project
QueueFree.zip
There are two instances of the same class which has an overridden queue_free(). I instantiate them both in the same manner and treat them almost identically except one reference is held in a typed variable and the other is held in an untyped variable.
When I call queue_free() on both of them, the custom queue_free() implementation is only called on the untyped variable reference.
Object-oriented inheritance should not be broken just based on the type assigned to a variable. (This bug took a real long time to isolate.)

Also, let's say I have a script with this queue_free override:
func queue_free():
	print("emit")
	super.queue_free()

Inside this script, if I call queue_free() nothing will be printed, which is wrong to me (?). I need to call self.queue_free() to have the expected result.
I'm not sure it's linked so tell me if I need to open a new issue for this.

Overriding non-virtual native methods is not supported. See #72608.

authors: Gastronok dalexeev quantumcode-martin


text:
GraphNode can connect one of its right side sequence ports to its own left side sequence port

Godot version
v3.3.3 stable (Mono build)
System information
Windows 10
Issue description
GraphNodes with sequence ports on both sides can connect any of their right side sequence ports to their left side sequence port, effectively allowing them to call themselves infinitely.

Naturally this immediately overflows the stack as soon as a scene with a node with this script attached is run.

I am unsure that this is intended behavior, but I'm choosing to report it as a bug rather than a proposal to change it because I can't think of any situation where this wouldn't simply cause problems.
Steps to reproduce
In an empty project:

Create a VisualScript resource.
Attempt to connect the right side sequence port of a GraphNode with pins on both sides to its own left side sequence port.

From the reproduction project:

Note how the Type Cast GraphNode's "yes" and "no" sequence ports connect to its own "Is Object?" sequence port.

Minimal reproduction project
GraphEditNodeConnectingToItselfTest.zip

Already fixed in #50413/#51208.

Closing as per above comment.

authors: KoBeWi MagdielM kleonc


text:
Freeze after suspend/sleep - Godot 4.0 Alpha 2 - Ubuntu 20.04.1, GeForce GTX 1660 Ti, nvidia-driver-470, Vulkan

Godot version
v4.0.alpha.custom_build [79077e6c1]
System information
Ubuntu 20.04.1, GeForce GTX 1660 Ti, nvidia-driver-470, Vulkan
Issue description
With a fresh alpha 2 build on Ubuntu 20.04.1, Godot Editor always freezes after putting the system to sleep (suspend) and then logging back in. This is with a new and empty project. Please see the steps to reproduce.
The following error messages came out:
ERROR: Vulkan: Did not create swapchain successfully.
at: prepare_buffers (drivers/vulkan/vulkan_context.cpp:1880)
ERROR: Condition "err" is true. Returning: ERR_CANT_CREATE
at: swap_buffers (drivers/vulkan/vulkan_context.cpp:1956)
Steps to reproduce
To reproduce: Download Godot 4.0 Alpha 2 tarball. Extract and cd into root of contents and run scons -j8 platform=x11. Run Godot editor with a new empty project. Put Ubuntu to sleep (suspend). After logging back in, Godot editor is frozen every time. The godot process must be killed to fix it.
Minimal reproduction project
New and empty project.

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

authors: Calinou julianrotheric


text:
GD Scripts changed externally not properly reloaded

Godot version
v4.0.alpha4.official [f47097973]
System information
macOS Monterey 12.2.1, Macbook Pro M1Max
Issue description
If a script is changed externally (e.g. in a different editor) Godot detects this and ask if the script should be reloaded.  When clicking "reload" the editor window is not updated with the new changes. The old version is retained even if I close and reopen the (internal) code editor window. Selecting File >> Soft Reload Script  is is also not updating the editor.
When running the project, the updated script is used so it seems to be an issue with the code editor only.
Steps to reproduce

Create new project
Add a scene and a node
Attach a script to the node and save
Edit the script in an external editor (e.g. vim, vscode)
Switch back to Godot and click reload script

Minimal reproduction project
No response

@frklan Can you reproduce this in 3.4.3?

@frklan Can you reproduce this in 3.4.3?

No, 3.4.3 does not behave the same: when I change a script using another editor, that change is detected and show in the internal editor as soon as I switch back to Godot.
(Actually, I find that the automatic reload without confirmation is a much nicer experience. But that's a topic for another issue I guess 😸)

I ran into this as well, I've noticed that if there is a runtime error, Godot will pull up the old version of the script in the internal editor. If the user edits the file and saves when looking at the file inside of Godot it will remove any external edits made since the project was opened.
It looks like the reload that happens on project load works perfectly, but it isn't being updated while the project is still open.

I only just went to report this same issue, Ive experienced on every single version of Godot 4 that ive used... grabbing them from the precompiled area the alpha pages on the site links to.
Im doin 2 projects that have some shared code so on linux ive been using a soft-link folder and get notifs about the source being different constantly and just copy pasting the same code back into the file on each editor on both projects when i make a change lol -- It only properly reloads the changes if the project closes and reopens unfortunately x-x

I've had no real issues with vscode and Godot 4.0 until recently, probably alpha 13 or after.   now though the internal editor doesn't seem to pickup any external changes to scripts.

I can confirm that editing emacs is doing the same issue.

Can you test https://github.com/godotengine/godot/pull/59523 ?

I just tried this patch. It does not fix the issue for me - the script editor still shows the old file contents until godot is restarted.
It does detect the file changing, since editing the script file in Godot and then re-saving it externally shows the "this file has changed" dialog (twice, actually!), but clicking "reload" there still leaves the script editor with outdated code.

Same as @RedMser, https://github.com/godotengine/godot/pull/59523 does not fix it.
https://github.com/godotengine/godot/pull/63224 does fix the issue for me though, so it should be mentioned.

Rough Comparison video:

Left: Old editor using https://github.com/godotengine/godot/pull/59523
Right: New editor using https://github.com/godotengine/godot/pull/63224
RightMost:  External editor (emacs)
You can see that it now works as expected :  new_godot <-> external_editor , while the older godot does not reload at all.

After a week of using that second patch https://github.com/godotengine/godot/pull/63224, I can confirm that it works well @Calinou

This should be fixed by #63224, and in the case of lsp, will be fixed by #66405.
For text files, some extra work is required, and that might be a different issue.

Fixed by #63224 and #66405.

It's not 100% fixed, more like 90%.  With LSP active, exports don't reflect updates when the editor is refocused.  They update when the scene is ran, or (seemingly) when an LSP intellisense thing pops up.  I also caught a different strange hard-crash bug after turning LSP off and changing some export values (i might have to open a separate issue for that one) which I discovered right at the end of this video.
https://user-images.githubusercontent.com/32113038/192352599-3110746a-936d-44fc-bd6b-c9c2097b982d.mp4
The engine crashed with this output to stdout (i ran the scene two times, then after focusing the editor a 3rd time it crashed):
Running: /home/grendel/docs/cpp/godot-engine/bin/godot.linuxbsd.tools.x86_64 --path /home/grendel/docs/godot/4.0/TestJun9 --remote-debug tcp://127.0.0.1:6007 --editor-pid 21310 --position 384,216 res://main.tscn
Godot Engine v4.0.beta.custom_build.e406badaf - https://godotengine.org
Vulkan API 1.2.0 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1650 with Max-Q Design

10
what
Running: /home/grendel/docs/cpp/godot-engine/bin/godot.linuxbsd.tools.x86_64 --path /home/grendel/docs/godot/4.0/TestJun9 --remote-debug tcp://127.0.0.1:6007 --editor-pid 21310 --position 384,216 res://main.tscn
Godot Engine v4.0.beta.custom_build.e406badaf - https://godotengine.org
Vulkan API 1.2.0 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1650 with Max-Q Design

100
what
terminate called after throwing an instance of 'std::system_error'
  what():  Invalid argument
Aborted

Even after building the current version of master, Godot 4 still has issues with external editor.
Here are my steps to recreate this:

Enable External editor (I'm using VSCode)
Create a new script attached to a node in Godot 4
In the _ready() function, add the lines var x = 0 and x /= 0
Run the scene that has the node with the script
Godot 4 will break on the exception and show the script in the editor, but this script will be the old version without any external changes.

Bonus: If the error occurs on a line number that's further than the unmodified version, there will be an additional error in the console that says scene\gui\text_edit.cpp:4887 - Index p_line = 22 is out of bounds (text.size() = 12). (In this case, the error occurred on line 23, and the original file loaded at project open was 12 lines long.) This shows that the parser is picking up the changes and throws the correct line number, but the editor just isn't reloading the file.

When saving externally, the script's source code will be updated, but the editor is not notified if saving via lsp. Can Resource.emit_changed be used for this purpose, or still need to use a separate signal?

beta2 shows this message on pressing Reload when this problem occurs:

core/object/object.cpp:1057 - Error calling from signal 'confirmed' to callable: 'ScriptEditor::ScriptEditor::reload_scripts': Method expected 1 arguments, but called with 0..

authors: Bitlytic Calinou RedMser Rindbee SpiceyWolf akien-mga cptchuckles dmaz duchainer frklan yedpodtrzitko


text:
drag-and-dropping a scene to the viewport doesn't instance it as a child of the currently selected node anymore

Godot version
4.0.alpha12 (works in 3.5.rc6)
System information
linux
Issue description
Drag and dropping a tscn file to the viewport instances it in the current scene.
It is added as a child of the root of the scene wereas it should be added as a child of the currently selected node.
Steps to reproduce

drag a tscn file in the viewport in a scene where the selected node isn't the root.

Minimal reproduction project
No response

This is intentional, see #51011 and godotengine/godot-proposals#2381.

Yes you need to hold Ctrl now.

authors: KoBeWi dzil123 mieldepoche


text:
JSON can not be loaded with ResourceLoader::load but the file can be correctly parsed

Godot version
4.0 beta3
System information
Garuda Linux
Issue description
There is a dedicated ResourceFormatLoader for JSON, but this loader can not load JSON files because the JSON class is not a Resource:
https://github.com/godotengine/godot/blob/61051a44ccacbe447f14538b5bb4b68a62fc896f/core/io/json.cpp#L582-L609
This method can correctly load and parse a json file, but when it gets returned, the Ref<Resource> becomes null, because it can not be converted into a Resource. This is because of this:
https://github.com/godotengine/godot/blob/61051a44ccacbe447f14538b5bb4b68a62fc896f/core/io/json.h#L39-L40
JSON is derived from RefCounted, but not from Resource. This seems to be somewhat indentional, but why is there a specific ResourceFormatLoader if it will never be able to load it?
I tried to change the base class of JSON to Resource and the ResourceFormatLoader can load it, but just changing the base class will probably not be enough and lead to other bugs. I just wanted to open this issue to point out that something needs to be done to fix this.
Related: #66820
Steps to reproduce

Create a new project
Create a JSON file
There will probably already be a lot of errors, because the editor tries to load the file.
Load it with ResourceLoader.load.
See that the returned Resource is null, but the error is OK.

Minimal reproduction project
No response

The problem (as noticed by @PucklaMotzer09 ) is that currently the inheritance tree looks like this:
Object
└── RefCounted
    ├── Resource
    └── JSON

This means that JSON cannot be loaded using ResourceLoader, because it's not actually a Resource.
One solution would be to make JSON a Resource, as initially suggested by @PucklaMotzer09 . Possibly we would have to move several types around, like FileAccess, which seems to be similar (also a file, but without a specific format).
Another solution is to make the ResourceLoader.load method return Ref<RefCounted>, which also seems like a huge change. Probably ResourceLoader would have to be renamed to RefCountedLoader :)
For now I'd like to submit a PR that makes JSON a Resource, and if we choose a different direction, please let me know and I'll amend it ;)

Fixed by #71390.

authors: PucklaMotzer09 akien-mga pfertyk


text:
Click on the debug option closes the menu

Operating system or device - Godot version:
Mac OS X 10.11.4 (MBP 2015 Retina) - Godot v2.1.1.stable
Issue description (what happened, and what was expected):
Each click on the debug option to select/deselect it, closes the menu.
So, in order to select four debug options I have to reopen the "Debug options" menu four times.

Steps to reproduce:

Open the "Debug options" menu.
Click on any of the options to select/deselect it.
Menu will close.

But isn't this a kinda standard behaviour? I think that these types of toolbar menus close on selection in most of the applications I use.
So if we change it, someone else will come and complain that he/she has to click somewhere else on the screen to actually close the menu...
Then how about making you have to use this menu less often instead?
By having the editor remember debug settings on a per-project basis so you don't need to set them each time you open the project.

@Hinsbart
Can you give an example of other application behaving in the same manner?
I think that if it was an ordinary context menu with a list of different actions AND checkboxes, then close on click would be expected.
But in this case, Debug options menu should act more like multiselect dropdown, so you can select all the options you need before you decide to close it by clicking an icon again or anywhere outside of the menu.
I have created another issue before about remembering the selection, please take a look at #7261.

So if you want that menu to keep open, then it should not be a menu, but a window with options in it, otherwise it will be inconsistent with standard behaviour.
I don't know any other application having a drop-down menu that stays open after clicking on a checkable item (at least on Windows and Linux).

@Zylann

I don't know any other application having a drop-down menu that stays open after clicking on a checkable item (at least on Windows and Linux).

You are probably talking about single select dropdowns, and what we have here is multi select.
Think about it. Let's say it has 10 options instead of 6, and you want to select 9 of them at once.
Currently, you would have to open the menu 6 times and select item 6 times, that's 12 clicks.
If menu stayed there until you decide to click outside or on the icon, that would be 7 clicks to select all the options.
Basically the more options the menu has, the more cumbersome the process becomes.

I agree with the amount of items, and the fact a menu could not close if it has checkable items.
My point is, it should be clear for the user that one kind of menu closes and another doesn't.
Hmm I'll amend what I said about "no other applications do that", because I just found another menu in Visual Studio that stays open when you check an item:

But again, this menu is specific and contains only checkable items. I don't think you'll find that in mixed menus.

But again, this menu is specific and contains only checkable items. I don't think you'll find that in mixed menus.

Agreed. 👍
Our "Debug options" menu also has only checkable items.

Tested on Windows 10, godot v2.1.2.stable and this seems to be fixed. Probably in this #7306

If we do that, I would also ask that we do this for the snap settings of the TextureRegion editor, and also Edit menu of the scene (though there are mixed types of items in this one :s)

Not completely fixed yet, I guess (though it should be junior-job from now on).

authors: Hinsbart Jylhis Zylann bojidar-bg igorskuhar


text:
[v4.0 Beta 17] - Android Editor Runs, But Crashes When Opening Project?

Godot version
v4.0 Beta 17 Android Editor
System information
Android Tablet / Android OS Version 9 / 3GB RAM
Issue description
Hi,
Tried running v4.0 Beta 17 Android editor on my Android tablet.
The IDE runs, but crashes when opening up a project?
The tablet has:

Android OS version 9
3GB RAM

What are the official system requirements for v4.0 Beta 17 Android editor on Android?
Let me know, thanks!
Jesse
Steps to reproduce
Open a project on the v4.0 Beta 17 Android editor on Android device - it crashes?
Minimal reproduction project
N/A

also crashes on my pc
Godot Engine v4.0.beta17.official.c40020513 - https://godotengine.org
OpenGL Renderer: NVIDIA GeForce GTX 1080/PCIe/SSE2
Editing project: F:/project mzd/godot/mzd
ERROR: Condition "!method" is true. Returning: 0
at: get_builtin_method_hash (core/variant/variant_call.cpp:1348)
ERROR: Error getting method typed_assign, hash mismatch.
at: gdextension_variant_get_ptr_builtin_method (core/extension/gdextension_interface.cpp:480)
ERROR: Condition "!method" is true. Returning: 0
at: get_builtin_method_hash (core/variant/variant_call.cpp:1348)
ERROR: Condition "!method" is true. Returning: 0
at: get_builtin_method_hash (core/variant/variant_call.cpp:1348)
Godot Engine v4.0.beta17.official.c40020513 - https://godotengine.org
Vulkan API 1.3.205 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1080

We are not talking about your pc - create a new bug report please

Tablet system specifications are attached

@BetaMaxHero Please upload a minimal reproduction project to make this easier to troubleshoot.
What's the name of the tablet device?

Hi,
Android tablet is below:
https://ivankyo.com/products/vankyo-matrixpad-s20-10-inch-android-tablet
Loading below project:
https://github.com/BetaMaxHero/GDScript_Godot_4_T-Story
Jesse

Sorry:
I opened Godot v4.0 Beta 17 Android editor and created a new project and changed to compatibility rendering.
Still crashes when opening the actual editor?
Jesse

Is there something I can do when running the editor to show debug info before it crashes?
Little lost here - please advise

Hi,
I tried the 4.0 RC1 Android editor on my new Samsung Galaxy S23 Ultra smartphone with 12GB RAM, runs fine.
(screen is too small to use - have poor eyesight)
I want to buy a new Android tablet soon to run Android editor.
How much RAM is required for Android editor to run?
(would 4GB RAM work?)
My old Android tablet with 3GB RAM did not run the Android editor.
Let me know, thanks!
Jesse

@BetaMaxHero This is not the channel to ask support questions. Use Discord or forums

authors: BetaMaxHero Calinou Zireael07 shafnaz


text:
.NET: Non SCREAMING_SNAKE_CASE constant names are converted incorrectly

Godot version
4.0.rc4.mono (e0de3573f)
System information
Windows 10
Issue description
Constant names that are not in snake case are converted with an incorrect case in dotnet.
This happens, for example, with the constants in the ECS class in godex.
Example:
Name in gdscript:
ECS.BtApplyForces
Name in dotnet:
public const long Btapplyforces = 11;
Steps to reproduce

Have a non snake case constant in a class (like CamelCase)
Generate the mono glue
Check the name in dotnet

Minimal reproduction project
N/A

The name converter assumes constants follow the Godot naming convention. Changing this would result in breaking compatibility and we're late in the RC phase, so I don't think we'll want to change this until 5.0.

I see, thanks.
I'll work around that in the c# side, then.


text:
Parallelize rigid body islands resolution

Operating system or device - Godot version:
Godot 2 - 3.0
Issue description:

In this loop each iteration is indipended from each other. I think this is a good opportunity to parallelize the physics engine. We could have a number of worker threads (tunable by the user thorugh a project property or through a new method of the PhysicsServer interface) and dispatch the islands to the different threads trying to balance the number of constraints each worker thread will process.
This should give a big speed up for cases when we have many ragdolls, as the task of solving multiple ragdolls can be spread among different cores/hw threads.

indeed, physics work in general was planned for godot 3.1
On Wed, Feb 1, 2017 at 7:27 PM, m4nu3lf notifications@github.com wrote:

Operating system or device - Godot version:
Godot 2 - 3.0
Issue description:
[image: parallelizable_code]
https://cloud.githubusercontent.com/assets/5478365/22528782/a7d5757e-e8cc-11e6-8b44-7ab7436f6f56.png
In this loop each iteration is indipended from each other. I think this is
a good opportunity to parallelize the physics engine. We could have a
number of worker threads (tunable by the user thorugh a project property or
through a new method of the PhysicsServer interface) and dispatch the
islands to the different threads trying to balance the number of
constraints each worker thread will process.
This should give a big speed up for cases when we have many ragdolls, as
the task of solving multiple ragdolls can be spread among different
cores/hw threads.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7702, or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2xSTi9KxaU5qXQyRVH1QbGNTsa0wks5rYQbCgaJpZM4L0eHx
.

Cool, If I can carve some time and efforts out of my spare time I could participate, but I'm not sure I will be able to, so for now I'm just creating these issues so that the things I've noticed don't get forgotten.

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!

authors: m4nu3lf madmiraal reduz


text:
on_delta_receive: Ignoring delta for non-authority or invalid synchronizer

Godot version
4.1.beta1
System information
Linux Mint 21.1; Kernel: 5.15.0-73; CPU: AMD Ryzen 9 3900X; GPU: AMD 5700XT, Vulkan
Issue description
When attempting to create a 3 player chat program. I am getting an error and I can not trace how or why it is happening. I believe it is something that is mis-configured but given the documentation and examples I do not directly see anything wrong with the code. I think it might be helpful if the error could perhaps provide additional debugging such as node that is causing the problem:  https://github.com/godotengine/godot/blob/37d1dfef9d81aade27ab0c56fc6b6f12f6a08045/modules/multiplayer/scene_replication_interface.cpp#LL771C9-L771C13
E 0:00:28:0433   on_delta_receive: Ignoring delta for non-authority or invalid synchronizer.
  <C++ Error>    Condition "true" is true. Continuing.
  <C++ Source>   modules/multiplayer/scene_replication_interface.cpp:774 @ on_delta_receive()

Steps to reproduce
I created a 3 player game with two synchronizers one for the host and one for the client. I then use the MultiplayerSpawner to instance the scene and set_multiplayer_authority() on both the client and the host side. But any time a message is sent to the server by either the second client of the third client the opposite (2nd or 3rd) client will generate this error. I also believe that as a result of the error the message does not get sent to the clients but only makes it to the host. But I could be wrong in trying to understand how this all works.
The key for reproduction is to start 3 instances, 1 as a host the the other 2 can just join and the error will start happening.
Minimal reproduction project
ChitChatv0.1.zip

provide additional debugging such as node that is causing the problem

From the actual condition I don't know if that's possible, the check could be made clearer in some cases but it's hard to tell which of the conditions that is fired in this case, I'll take a look

@AThousandShips good point. In 2 months I will have a lot more free time and worst case scenario that is when I will dig into the engine and attempt some deeper debugging. I was hopping that node might be set by then, and that it would also be able to provide the path of that node for additional troubleshooting. This situation is most likely due to a poor implementation on my part, but was still something I encountered.

same problem here, Im using a MultiplayerSynchronizer node to sync the player id on spawn and the player position on physicsprocess. Everything was fine at first but for some reason the position isnt syncing anymore, and I get this on_delta_receive error every frame. Not sure if this is related, but I also get on_spawn_receive: Condition "parent->has_node(name)" is true. Returning: ERR_INVALID_DATA at the start of the communication, when I spawn the hosting player's player in the client (which is the one who's position isnt syncing).

Error "on_delta_receive..." cause when u do bad configure with multiplayer_authority on MultiplayerSynchronizer node which using for player input. By default MultiplayerSynchronizer node working on serverToClient mode, if u want to change direction to clientToServer u must set_multiplayer_authority(client_peer_id) on MultiplayerSynchronizer node on server and on client. That mean when other players joins to server u must set player_input synchronizer node on that player to his unique multiplayer id.
Example: server has 2 joined players, that mean it has 2 MultiplayerSynchronizer nodes(one for each player) which uses for player input. Multiplayer authority on each of this node on server == unique multiplayer id of client.
Client have 2 players - first - self, and second - enemy. Each player have MultiplayerSynchronizer node, one have multiplayer_authority == miltiplayer.get_unique_id(), but enemy sync node have multiplayer authority == 1(by default when server replicates) - its mean u got invalid states on MultiplayerSynchronizer nodes on server and client. That mean u must ON CLIENT change multiplayer_authority on enemy player_input(MultiplayerSynchronizer) node to enemy_unique_multiplayer_id. Hope its helpful

@boxlifestyle I appreciate the information, but can you format your text when you have time. I am finding it difficult to break out what you are stating. I think using the code block for formatting would help immensely with understanding.

@FeralBytes Better to show u simple example. Pay attention at callback on client "_on_players_child_entered_tree" on else branch. input.set_multiplayer_authority(int(str(node.name))) - with this u synchronizing with server of who have authority at this node. After this, ur error is gone.
Multiplayer Synchronizer Server.zip
Multiplayer Synchronizer Client.zip

@AThousandShips good point. In 2 months I will have a lot more free time and worst case scenario that is when I will dig into the engine and attempt some deeper debugging. I was hopping that node might be set by then, and that it would also be able to provide the path of that node for additional troubleshooting. This situation is most likely due to a poor implementation on my part, but was still something I encountered.

@FeralBytes Hi!, have you investigated it?, I'd love that error to have more info :P. I'm getting some of those errors and I have many MultiplayerSinchronizers scattered through the scene tree so it's not obvious which one's wrong.

@JuanFdS I am sorry I did not get back to this. I have been working on other project that have not involved Multiplayer. If you could post some additional details with the errors that you are seeing that may be helpful to the developers.

I was struggling with the same problem and I managed to find the answer if anyone needs it. The problem occurs when we have a separate project for the client and a separate project for the server. To give the client authorities over a given node made by MultiplayerSpawner we have to do it on the server side and on the client side. And here a small implementation error may appear. Here is my example:
Server side:
public override void _EnterTree() { SetMultiplayerAuthority(int.Parse(Name)); }
Client side:
	public override void _EnterTree() 	{ 		SetMultiplayerAuthority(Multiplayer.GetUniqueId()); 	}
It will work if there is only one client attempting to connect, but when the second one connects we get on_delta_receive: Ignoring delta for non-authority or invalid synchronizer
After the second client joins the server, two nodes will be created on it, so the EnterTree() method will be called twice and the second client's PeerId will be assigned to both nodes, even though the first node should belong to the first client. The server understands that something is wrong and that's why it throws this error.
My current solution is to change client side to:
	public override void _EnterTree() 	{ 		SetMultiplayerAuthority(int.Parse(Name)); 	}
or have another another variable that is being set on the server side.
I hope it will help 😄

authors: AThousandShips FeralBytes JuanFdS boxlifestyle jorgegayoso kasperserzysk0


text:
C#: Array.Contains() doesn't work properly with enums

Tested versions
4.4.dev3
System information
Windows 11 - Godot 4.4.dev3
Issue description
I have an enum called ItemType, belonging to a custom resource called ItemManager:

When I try to check if an Array<ItemType> contains STATS from this enum, unexpected behavior happens:

Steps to reproduce

Make a new C# project
Make a new custom resource on C# with a public enum
Make a typed Array with that enum, containing one of it's elements
Check if that element is inside the array

Minimal reproduction project (MRP)
N/A

I couldn't reproduce this on 61accf060515416da0, potentially it's been fixed between dev3 and that commit.
For that commit, cs_array_contains.zip has the output:
Enum Array: [0, 1, 2]
  Contains MyEnum.A (0): True
  Contains MyEnum.B (1): True
  Contains MyEnum.C (2): True
Int Array: [0, 1, 2]
  Contains MyEnum.A (0): True
  Contains MyEnum.B (1): True
  Contains MyEnum.C (2): True

I couldn't reproduce this on 61accf060515416da0, potentially it's been fixed between dev3 and that commit.
For that commit, cs_array_contains.zip has the output:
Enum Array: [0, 1, 2]
  Contains MyEnum.A (0): True
  Contains MyEnum.B (1): True
  Contains MyEnum.C (2): True
Int Array: [0, 1, 2]
  Contains MyEnum.A (0): True
  Contains MyEnum.B (1): True
  Contains MyEnum.C (2): True

Were you able to reproduce it on normap 4.4 dev3 though?

I could not reproduce it on 4.4 dev3 either; the output is the same as the current head. If you're certain this is an engine bug and not a project bug, can you compare your code to the zipped project I linked and make an MRP?

Sounds like a duplicate of https://github.com/godotengine/godot/issues/98309. Make sure the array property is typed when serialized to the scene, it should look like: Array[int]([0, 1, 2])

Ah interesting, thanks for linking that. Yeah that seems to trigger specifically for int arrays and the value 0 as when I change the exports (and the int array print, whoops!) in the project above to
[Export] Array<MyEnum> enumArray = new();
[Export] Array<int> intArray = new()

the output changes to
Enum Array: [0, 1, 2]
  Contains MyEnum.A (0): True
  Contains MyEnum.B (1): True
  Contains MyEnum.C (2): True
Int Array: [<null>, 1, 2]
  Contains MyEnum.A (0): False
  Contains MyEnum.B (1): True
  Contains MyEnum.C (2): True

Sounds like a duplicate of #98309. Make sure the array property is typed when serialized to the scene, it should look like: Array[int]([0, 1, 2])

Doing new Array<int>{0} did not work
([0]) doesn't work

Even if I don't use 0 and use another index like 1, it doesn't work

Sounds like a duplicate of #98309. Make sure the array property is typed when serialized to the scene, it should look like: Array[int]([0, 1, 2])

Doing new Array<int>{0}; did not work ([0]) doesn't work

they're referring to how the array is serialized by the resource/scene. For example, in the example project I linked above, main.tscn has these two lines in it (in the case of having a non-null default value):
enumArray = Array[int]([0, 1, 2])
intArray = [null, 1, 2]

Sounds like a duplicate of #98309. Make sure the array property is typed when serialized to the scene, it should look like: Array[int]([0, 1, 2])

Doing new Array<int>{0}; did not work ([0]) doesn't work

they're referring to how the array is serialized by the resource/scene. For example, in the example project I linked above, main.tscn has these two lines in it (in the case of having a non-null default value):
enumArray = Array[int]([0, 1, 2])
intArray = [null, 1, 2]

https://github.com/godotengine/godot/issues/98595#issuecomment-2442814590
The array is already set to another value in this function, which is called in an Initialize() function of the ItemManager
In the same node script where the behavior happens:

A workaround I found was just using int[] instead of Array<int>, since Godot thinks of int[] as a PackedInt32Array. But the issue persists with normal Arrays.

Can someone add the confirmed label?

authors: InkONat a-johnston raulsntos


text:
[DOCS] AnimationPlayer prop API fixed

I believe this should fix the problem since I've switched the exposed API back to normal.
The only properties modified now are just the ADD_PROPERTY tidbits that don't have any risks attached since they're just binding the prop name to a getter and setter. I'm no longer changing the names of those getter/setter.

cc @akien-mga

@akien-mga LGTM, the error message by godt start (irc) is gone. Thanks.

source: gharchive/pull-request

authors: capnm willnationsdev


text:
Proposed change to close issue "#6382 - Properties in the inspector lacking tooltips"

This is a proposed change to close godotengine/godot#6382 issue
Basically, the change does this: traverse classes docs so that all properties from inherited classes have tooltips accordingly
If we are seeing the properties of a Node2D, not only it's properties will have tooltips (like it was before), but also CanvasItem (from where Node2D inherits from) properties will have their tooltips.

Sorry guys!!! but i was done a unnecessary git pull on my local branch, when i doing a fix for this PR... and now other commits are being part of the PR...
Would this require me to close the PR and open a new one?

You don't have to create a new pull request. Just clean up your local branch and then force push to GitHub. Make sure that you really have all your changes integrated before force pushing, though, otherwise you might lose your work.
Personally I find it helps to do the cleanup work on a different branch than the one I use for the PR and then cherry-pick the changes on the PR-branch once I'm done (often after doing a git reset --hard master on the PR-branch). But, as noted above, make sure that you don't accidentally overwrite your changes when performing operations such as resetting/amending/force pushing.

reopen after cleaning local branch.. thx for the help @hoelzl !

Could you squash the two commits together? See PR workflow for instructions.

Done

Could you squash the two commits together? See PR workflow for instructions.

Thanks for fixing this!

authors: Sslaxx akien-mga carlosfvieira hoelzl


text:
fixed PrismMesh size property

This pull request is to fix an issue I found today on prism not being able to resize (and having only X and Y showing on the inspector).
This PR restore, I think the original functionality.

You can check against the latest build, if you create a mesh and add a prism primitive, you can't resize it.
I have also added another line to the already huge .gitignore file, I hope you don't mind. Wi work with VS Code.
This is my first pull request, I hope I did it right.

The fix looks good, but you should have only one commit instead of four presently. You can fix that by rebasing the branch to remove or squash the unnecessary commits (either keep only the first one which is the needed fix, or squash them all together, should be the same result). Then you can update this PR by force-pushing the new branch.
See PR workflow for details.

Also, your commits are not linked to your GitHub account presently, as the email address defined in your git config (see e.g. https://github.com/godotengine/godot/commit/b27b1a99a029016e9256fb28a04b417855fc4b47.patch ) is not known to GitHub. It's perfectly fine as is, but in case you want to reclaim those commits as made by your account @Toshiwoz, you can add this email as secondary GitHub address.

Great, I think now it looks better, I've added my other email so that this pull will be recognized as mine.
Thanks @akien-mga.

Thanks!

Cherry-picked for 3.0.7.

authors: Toshiwoz akien-mga


text:
Keep GDScript functions in stack while yielding

This prevents GDScript functions from leaving the stack too soon when they are resuming from yield, allowing the ones expecting it to finish to know the caller.
Helps debugging cases when you use: yield(function_which_yields(), "completed") since now it shows the call that resumed that function.
Also show the function names in the debugger stack, which helps identify the stack (not sure why that was commented out, it's been like this since the first commit). And show function/script/line when resuming from yield after instance is gone, to help identify the issues.

This is a remake of #28815 (I thought I could reopen but it's not possible after force-pushing).

This will be great, these types of errors have been so difficult to track down.  From time to time I have desired a graceful way to check / ignore them, in situations where things are shutting down or the game is closing and yields were out and resuming as resources are vanishing.

Related to #24199.

Thanks!

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

authors: akien-mga avencherus bojidar-bg vnen


text:
Fixes issue with project_default_theme not being cleaned up

Prevents errors on shutdown when using a custom theme due to the project_default_theme global variable not being explicitly dereferenced in the engine cleanup phase.

Thanks!

authors: SaracenOne akien-mga


text:
fixes #33439. The feature now changes according to the feature profile.

Need to make the dock tree more synchronised with the feature profile manager.
Bugsquad edit: This closes #33439.

If you desire to keep helping the engine, consider adding this hooks to your .git/ folder, just follow the instructions: https://github.com/godotengine/godot/tree/master/misc/hooks
You may also want to check the code guidelines: https://docs.godotengine.org/en/3.1/community/contributing/code_style_guidelines.html

One last trailing space left.
Also, when you're done, squash your commits: https://docs.godotengine.org/en/3.1/community/contributing/pr_workflow.html#mastering-the-pr-workflow-the-rebase

@YeldhamDev is it why my travis tests are failing?

Yes, it also checks for formatting.

You accidentally mixed some older commits into your branch.

@YeldhamDev you can review the PR now. I have fixed the formatting errors. I guess it fulfils the required guidelines.

You accidentally mixed some older commits into your branch.

How should I resolve it? Should I fixup some more commits?

I think it's better to close this push and try again.

authors: YeldhamDev code-xD


text:
Backport RootMotionView icon from the master branch

This makes RootMotionView display with a proper icon in the editor.
This closes https://github.com/godotengine/godot/issues/50698.
Preview

@Calinou Shouldn't the icon have the color tone changed to match the shade of red used in 3.x?

Fixed.

Thanks!

Cherry-picked for 3.3.3.

authors: Calinou akien-mga


text:
Fixed Reduntant assignement of arr[i + max]

Fixes #50848

Thanks for the contribution but there's already another PR for it: #50870.

Thanks for the contribution but there's already another PR for it: #50870.

ok :)


text:
Fixed a typo

"capture_propagation" member documentation description was missing the second 'p' in "propagation". Fixed this minor typo
This is for the 3.4 branch because that is where I was able to find the BakedLightmap in the beginning. I'm hoping this qualifies for the "change is only relevant for that branch" clause.

This is for the 3.4 branch because that is where I was able to find the BakedLightmap in the beginning. I'm hoping this qualifies for the "change is only relevant for that branch" clause.

The change should be made in 3.x instead of 3.4, since the change is also relevant for the upcoming 3.5.

Closing this PR and resubmitting under 3.x branch

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

authors: Calinou QueenOfSquiggles


text:
Add translation links to shader errors

This adds all missed translations links to shader errors and warnings (to implement localization for those messages).

I forget the details but for translation: phrases that are parameterized are harder to translate but exact phrases are easier.
Like "The varying '%s' is declared but never used." has a parameter. Not the residential translation expert though. @NathanLovato

authors: Chaosus fire


text:
Fix Object not considered Object class in typed Array

Fixes https://github.com/godotengine/godot/issues/53771.
Basically the same as https://github.com/godotengine/godot/pull/58250 but for native Object based types.
Also fixes not being able to modify a typed array with a setter in a tool script using the inspector, as mentioned in https://github.com/godotengine/godot/issues/53771#issuecomment-1037732038. However, does not fix the issue in https://github.com/godotengine/godot/issues/58285.

BTW, I've slightly edited the original post because writing not fix #58285 actually triggers the check that will make the PR close the issue.

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

authors: akien-mga mphe vnen


text:
Properly scale depth in bokeh_dof effect

Fixes: https://github.com/godotengine/godot/issues/62678
This is an error from copying OpenGL code. In Vulkan the depth buffer is stored from 0-1 while in OpenGL it is signed (-1 to 1). Everywhere else in the codebase the equivalent code scales depth to -1 to 1 before linearizing.

Seems to be working much better

Seems to be working much better

Thanks for checking!

Yes, it works very well. Thank you very much @clayjohn !
BTW, I just discovered this PR only because I happened to look at my issue. Is there a way to get notified when my issues or my subscribed issues get PRs attached without following the whole repo?
https://user-images.githubusercontent.com/632766/185241196-b16e0a42-369a-4157-b4c2-87095bdb705a.mp4

Is there a way to get notified when my issues or my subscribed issues get PRs attached without following the whole repo?

Not that I know of. You can choose to watch a repository for pull requests only, but this will still result in a lot of activity for godotengine/godot:

Thank you! 🎉

This is an error from copying OpenGL code. In Vulkan the depth buffer is stored from 0-1 while in OpenGL it is signed (-1 to 1). Everywhere else in the codebase the equivalent code scales depth to -1 to 1 before linearizing.

Will this cause a problem when OpenGL 3 support is added back to a future version of Godot 4?

This is an error from copying OpenGL code. In Vulkan the depth buffer is stored from 0-1 while in OpenGL it is signed (-1 to 1). Everywhere else in the codebase the equivalent code scales depth to -1 to 1 before linearizing.

Will this cause a problem when OpenGL 3 support is added back to a future version of Godot 4?

No, this shader code is only used by the Vulkan renderers. If we implement DoF in the OpenGL renderer it will use a different shader.

authors: Calinou clayjohn jcostello mhilbrunner nathanfranke tinmanjuggernaut


text:
Fix connection of animation "changed" signal in AnimationTrackEditor

Follow up #64647.
Since the signal connection method was unwillingly changed, there is a bug in the GUI update. This PR fix that.
Before:
https://user-images.githubusercontent.com/61938263/202873025-f8182d65-67c4-4c55-9fad-891332bbe407.mp4
After fix:
https://user-images.githubusercontent.com/61938263/202873031-f83f89f9-5a19-481f-8fd0-c1e2ddeb4d64.mp4
Also, the signal "tracks_changed" is almost equivalent to "changed", and there is no reason to exist it separately, so I remove that signal.

Thanks!

authors: TokageItLab akien-mga


text:
Add support for set graphNode's title font color

Close #82085

Did you mean to close this?

Superseded by:

#82129

Did you mean to close this?

I resubmitted once, maybe.... I can do something more correct?

You opened a new PR and closes this one manually, unsure why you did that

You opened a new PR and closes this one manually, unsure why you did that

I don’t know how to make the remote squash submit twice, or should I just continue to submit one?

Oh, just follow the instructions, do not open new PRs every time you make a new push

Oh, just follow the instructions, do not open new PRs every time you make a new push

Oh, this is helpful!

authors: AThousandShips SaNeOr


text:
Update CanvasItem.xml for proper y-sorting on sibling nodes

In order for sibling nodes to allow y-sorting, the parent node must also have y-sorting enabled.  Updated the documentation to reflect this.

Noticed I capitalized parent, when it shouldn't be.  Worth correcting and re-running tests?


text:
Enable use of Labels as Values feature in Clang when not wrapped by GCC

Split off from #77233. Tested on top of #92316, using the benchmark:
@tool
extends EditorScript

func _run() -> void:
	static_run()

static func static_run() -> void:
	var time_before := Time.get_ticks_msec()

	var r : int
	for i in range(10000000):
		var next : int
		var first := 1
		var second := 2
		for c in range(40):
			next = first + second
			first = second
			second = next
		r = next
	print(r)

	var total_time := Time.get_ticks_msec() - time_before
	print("Time taken: " + str(total_time))

In dev build, no notable difference. But in release build with lto=full, times went down from 16-18 seconds, to 13 seconds, i.e. ~20% improvement in speed.

Thanks!

authors: SlugFiller akien-mga


text:
Allow WASAPI multi-channel microphone input

Salvaging https://github.com/godotengine/godot/pull/96947
Support multi-channel microphone input by downmixing to stereo

Enhanced the WASAPI audio driver to support microphones with any number of channels.

This modification ensures compatibility with a broader range of multi-channel microphones, allowing for more versatile input handling in Godot.

I have a microphone with two audio inputs https://zoomcorp.com/en/ca/handheld-recorders/handheld-recorders/h3-vr-360-audio-recorder/ but have not set up to test this yet.