Add node active feature and corresponding lifecycle methods

Implements https://github.com/godotengine/godot-proposals/issues/7715 and is based on suggestions from users in that discussion :)
This change aims to accomplish 3 things:

Add a faster/more convenient way to disable a Node for debugging and gameplay purposes. See here.
Provide the groundwork for a more universal disable feature that can simplify workflows and eventually replace some existing "enabled" toggles. See here.
Provide new initialization and cleanup methods (i.e. lifecycle calls) that are dependent on active state so that users can run code only when a node is supposed to have an impact in the scene. See here.

I should also note that this PR is meant to pair nicely with and build upon the work of @torcado194 since it is distinct from https://github.com/godotengine/godot/pull/92377 due to working in both runtime and the editor, and leaving references to disabled nodes intact.
Active Concept
All nodes now have a property called node_active which determines their active state:

Similar to visibility, if an ancestor node is inactive, the child behaves as though it is inactive as well. To match visibility, a new method called is_node_active_in_tree() exists to check whether it should behave as active or inactive.
From discussions in https://github.com/godotengine/godot-proposals/issues/7715 we wanted an easy way to toggle/preview active state but some people noted a lot of icons in the scene tree already, so @snowdrama suggested an icon filter as seen here. It's a great idea that should definitely be added imo but it's probably best as it's own PR, so for now I added a new editor setting called show_node_active_checkbox which toggles the icon and is off by default to alleviate concerns of clutter. Here is that in action:
https://github.com/godotengine/godot/assets/11141862/02675524-d614-44db-8d10-c6a5833f2d27
An inactive node is not visible, does not process scripts/physics/collision/lighting/etc., and will not work as a valid camera (a special case because it did not previously check can_process). It works directly from the editor via these new buttons, a tool script that sets the node_active property, or from the inspector:
https://github.com/godotengine/godot/assets/11141862/c42c9141-1d63-43c2-b6ba-f844ac6c4d89
It also works in runtime! Simply set the node_active property or (in C++) use set_node_active to toggle it. You can connect to the node_active_changed signal to get a callback when the property has changed, or the node_active_in_tree_changed to get a callback when its "active in tree" status has changed. Here a script enables a node during a certain time frame and then turns it off again:
https://github.com/godotengine/godot/assets/11141862/5c9a4601-9615-44a1-a985-769739b7ec14
Lifecycle Methods
Thanks to feedback from @passivestar and others in the proposal, another useful aspect of this feature is new lifecycle methods for users to run initialization/cleanup code that is dependent on active state. The new _node_active() call is run when a node becomes active in tree or after _ready() when it enters the tree (if active). The _node_inactive() call is run when a node becomes inactive in tree or before _exit_tree() when exiting the tree (if it was active before that point). Now, users can run code like this:
func _ready():
	print("_ready")

func _enter_tree():
	print("_enter_tree")

func _exit_tree():
	print("_exit_tree")

func _node_active():
	print("_node_active");

func _node_inactive():
	print("_node_inactive");

And like before, it works both in the editor and in runtime:
https://github.com/godotengine/godot/assets/11141862/bb8dd374-6b8f-4d82-87d9-2f77fed1815f
Ultimately, this means you can put setup steps in _node_active so that code runs when it becomes active, not when the scene starts. This is useful for say an object that is culled by distance so that it only has an impact when the player gets closer to it rather than it having to do additional work to check whether it is culled in _ready().
There is room for further work here like adding a parameter to signal calling so that inactive objects do not receive them, but for now this is a good starting point for people to play with and covers the main use cases discussed in the proposal.
Other Notes
I generated and wrote out documentation descriptions for the new methods, notifications, and properties so let me know if that looks good and if there's other documentation I should edit as a result of this change. For example, it might be good to mention active state in the visibility section of the docs, but I wasn't sure how much I should mess with for now. I'm happy to help write explanations in the doc site as well to help explain the feature since I know communication of something like this is very important. I also added new test cases just to cover some simple scenarios but I can add more if necessary.
Thanks to everyone that helped shape this PR and I know that since this is a hefty change it will take some time to review/merge but I'm happy to clarify anything and make any necessary adjustments :) I'm hoping this will improve lots of workflows down the line, so let me know how it works during your testing! Thank you!

Tested, can confirm that these work:

Disabled node doesn't call _input and _process
Disabling a Node3D hides its children
Disabling Camera3D switches to another camera as expected
Lifecycle methods _node_active and _node_inactive work
node_active_changed signal works
Instantiating a scene with a disabled root node and a tool script doesn't call _node_active method on it in editor
Disabling a rigid body excludes it from the simulation, same with particles
Clicking on a checkbox while multiple nodes are selected properly toggles all of them just like the visibility toggle

Problems and nitpicks:

Disabling a CanvasLayer doesn't hide its children. Toggling its visibility does hide its children
Remote tab of scene tree doesn't have the checkboxes
Would be nice for checkboxes in the scene tree to have indication for "inactive in tree", just like the visibility icon
Disabling Environment doesn't have any effect, would be nice if it did (not necessarily for this PR)

I wasn't able to keep up with the discussion in the proposal thread but I'm pretty happy with this design. A much needed feature. The only thing missing is a native option for disabled nodes to ignore signals. Whether a disabled node will react to a signal can be handled by adding a new flag to ConnectFlags

Remote tab of scene tree doesn't have the checkboxes

Good catch! Being able to set active/inactive in the remote is super useful.

Would be nice for checkboxes in the scene tree to have indication for "inactive in tree", just like the visibility icon

That makes sense, I'm not sure how that would work with the blue checkbox icon, does it just add opacity to the visibility icon to make it grey? But I think this makes makes sense.
It might also be nice to update the icon to match the style of the other icons while we're at it rather than using the blue checkbox?
I threw together an SVG in Affinity Grey/Black for Dark/Light mode so I'd just need like file formats and export resolutions for them if we wanted to use them.

The only thing missing is a native option for disabled nodes to ignore signals. Whether a disabled node will react to a signal can be handled by adding a new flag to ConnectFlags

That would be valuable for sure! I think that part did get lost in the conversation, thanks for bringing it up.

I think this is a good feature usability wise, but to be honest, the process mode and visibility properties together achieve a similar effect and its good that they are separate to me. Adding a yet third state to coordinate both seems unnecessary and confusing to me.
Sure, It makes sense if you come from Unity, but Godot is not Unity and I think the solution should make more sense in the context of Godot.
So, instead of having an active mode, you could have the processing exposed in the scene tree (this an Idea I had for a while, and kind of the original intention when it was created) something like:

This way you can disable node visibility and not processing, and processing and no visibility. And this basically just reflects the state of the process mode similar to the eye reflects the state of the visibility, keeping the Godot core APIs cleaner and the editor interface reflecting what it actually happens internally.

@passivestar Currently, you have NOTIFICATION_PAUSED and NOTIFICATION_UNPAUSED that do exactly the same as setting a node active or not, though I am not sure there is a callback, though it should be possible to do this

Did you mean NOTIFICATION_ENABLED and NOTIFICATION_DISABLED? I know about those, but no, there's no callbacks for those currently
They are also not called when the node enters and leaves the tree. There's currently no place to put your code in so that it doesn't run when you disable a node in editor before running the game
There's no API that would be a contract for inactivity. There's no agreement. If you download something from the asset store, put it in your scene, change properties on it, and then need to temporarily disable it to check how things work without it and without losing your data, what do you do? Will disabling process on it work as if it was never in the scene? No, because it runs code in _ready() and _enter_tree() and most likely isn't checking the process mode before doing so. It wasn't designed with inactivity in mind, because inactivity isn't in Godot's lexicon
Everybody seems to be doing whatever. You say that disabling process should be good enough for runtime, some people say that it's better to take it out of the tree to properly "disable" it. Taking it out of the tree will at least trigger an actual callback that is exposed (_exit_tree), but you need a reference to a parent to add it back later. And it will be gone from the Remote tab of the Scene dock, which isn't very convenient either
To this day, after playing with Godot for over half a year I still have no confidence that when I disable something by setting its process to disabled it will actually become disabled.  If I disable a collider by changing its process mode, will it stop colliding? As I'm writing this, I genuinely don't remember. Right now I don't even remember if disabling process will also disable _input. To me it sounds like it won't, because just from the name of it I'd expect it to only disable _process and _physics_process. This is confusing. Maybe I'm a bit slow and should learn the engine more to better appreciate it. Or maybe there's a better design
Having visibility and processing separately makes more sense in code than it does in the scene dock. More often than not you'll want to disable game entities completely, not just their visibility or their processing. More often than not I'll have to click both buttons
This isn't copying Unity for the sake of copying Unity. Unity has its problems. This is taking a look at how Godot solves inactivity and thinking if it can be improved. Ending up with a system that is similar to Unity in some ways isn't a problem when there are things that it solves better, namely in-editor UX for disabling objects, playmode debugging experience and having an API that actually gives you confidence that an object will become disabled as you expect no matter if it's your code or not
This PR could be the first step to solving these issues. The exact API can be refined to make sure it works for Godot and makes sense to everybody, both existing and new users

At first glance, I expect this feature to be a shortcut to set the Node’s process_mode to disabled and also turn off visibility in one click… So from a usability perspective, I would be confused about why this new feature isn’t modifying these properties. (Please correct me if I’m wrong.)
Is there any way to add the new lifecycle functionally while also using the existing viability and process_mode?

If we add activity, Godot will have visibility, process mode, and activity, which is the same as the former 2 with some extras. It just feels redundant to have multiple basically competing systems. You can toggle visibility, process mode or activity and each has a callback that the node is supposed to react to, with lots of overlap. Sounds like a mess.
I'm also in favor of process toggle, but to make it a proper replacement for activity, it needs some improvements. If disabling a node does not yield expected results (like in camera or colliders), it needs to be fixed to properly handle disabling.

If I disable a collider by changing its process mode, will it stop colliding?

Disabling active of collider won't stop colliding either, or at least nothing in code indicates so.

@passivestar

Did you mean NOTIFICATION_ENABLED and NOTIFICATION_DISABLED? I know about those, but no, there's no callbacks for those currently

They are also not called when the node enters and leaves the tree. There's currently no place to put your code in so that it doesn't run when you disable a node in editor before running the game

Oh yes sorry, I forgot we renamed them in 4.0. I see why the workflow you intend to do is cumbersome. One possibility may be to make something like NOTIFICATION_ACTIVATED that is called when the node is enabled, so you can use it with NOTIFICATION_DISABLED and it would work as you suggest. Likewise no harm in adding callbacks if there is demand.

To this day, after playing with Godot for over half a year I still have no confidence that when I disable something by setting its process to disabled it will actually become disabled.

Disabling processing effectively disables it in practice, node does nothing. No processing, no input, no physics (which you can decide whether you want it to make it static or just remove it from processing) etc. That is warranted. It is still added to the scene and initialized, of course, but no processing code will be executed that comes from the scene tree, input, physics etc. That is a contract that the engine honors and it does in a way it makes sense. It also adds the possibility to specify what can be paused and how, which is really helpful when you want to pause the game state.
 There is no such thing as a globally active thing because it does not make sense in how the engine works, and hacking it will make things worse. It sounds to me that this is something that needs better documentation, as it is new to 4.0 and likely has not much examples.

Having visibility and processing separately makes more sense in code than it does in the scene dock. More often than not you'll want to disable game entities completely, not just their visibility or their processing. More often than not I'll have to click both buttons

Actually you would be surprised that most of the time you don't want to do both and this is not a problem Godot users face often (as you can see it's been a decade, so it shouldn't surprise you this is not very requested). The most common thing you want to do in games it do disable objects when not in view (something Godot does very well), or disable them when not active (due to gameplay reasons) or in the right room, but you don't necessarily want to hide it because it still needs to be visible. Of course, if you also want to show/hide them its also super easy.
In Unity, users disable objects for different reasons, most of the time because they can't freely take them in/out of the scene. As in Godot doing this is not really a problem and users are very accustomed to just remove/readd the node.
This is why adding this to Godot feels pretty foreign, specially when you are used to how the engine works.
That said, I think having a process_disable property to completely disable the node processing no matter what is set in process_mode, and expose it in the scene tree dock does have a lot of value in cases where you want to edit a level and more visually leave parts of the scene disabled until you can enable them later.
I agree that going to the inspector and changing the process mode just for this is quite cumbersome and complex.

I think this is a good feature usability wise, but to be honest, the process mode and visibility properties together achieve a similar effect and its good that they are separate to me.

I 100% understand why they're separate as well, and I wouldn't want to change that, so the intention wasn't to affect that directly. Instead the idea behind this for me was to improve the experience around when it's desired to set and unset both without removing the object from the tree. It's totally valid to want to change one or the other, and we intentionally don't change that, instead opting for a single override for when we desire it to change both, that continues to respect the state of those separate values.

At first glance, I expect this feature to be a shortcut to set the Node’s process_mode to disabled and also turn off visibility in one click… So from a usability perspective, I would be confused about why this new feature isn’t modifying these properties. (Please correct me if I’m wrong.)

I wanted to make sure we continued to respect that separation, so in the implementation the active state acts as an override that changes both without changing the underlying state. When returning a node to the active state it still respects the state it was in before becoming inactive.
So for me I wanted to avoid any kind of "hidden" or "magic" changes.
my_node.visible = false
my_node.node_active = false
my_node.node_active = true
# we never modified the underlying visible flag, so the expectation is that visible should still be true
# setting node_active to true doesn't magically change the state of the underlying visible property
print(my_node.visible) # false

Keep in mind the goal is that this does correctly call things like visibility_changed as well and is consistent with some other visibility quirks when polling for the visibility state, and needing to use is_visible_in_tree() instead of polling the visibility property itself.

# In both cases the value of the property is true, but it's not visible
# due to something other than the property itself modifying it's visibility
my_parent_node.visible = false
my_child_node.visible = true
print(my_child_node.visible) # true
print(my_child_node.is_visible_in_tree()) # false

my_node.visible = true
my_node.node_active = false
print(my_node.visible) # true
print(my_node.is_visible_in_tree()) # false

I'm also in favor of process toggle, but to make it a proper replacement for activity, it needs some improvements. If disabling a node does not yield expected results (like in camera or colliders), it needs to be fixed to properly handle disabling.

If I disable a collider by changing its process mode, will it stop colliding?

Disabling active of a collider won't stop colliding either, or at least nothing in the code indicates so.

From my perspective the this implementation is an improvement here. The name process_mode is ambiguous enough to be confusing, the intuitive answer is stops calling _process and _physics_process since process is right in the name. However this is actually apparently not the case. Currently colliders do in fact get disabled when process_mode is disabled, but cameras don't?
This attempts to solve this by having a unified definition that a node that is not active should not have any affect including physics, collision, cameras, scripts, viability, nothing. So this acts as an override for all of those at once, while also continuing to respect the individual choices for if/when it gets re-enabled.

@Snowdrama Yes, as I said, I think a simpler version of this PR that just disables processing and exposes this in the scene tree dock, while leaving visuals alone makes more sense.
from code you could use it like:

my_node.visible = false
my_node.process_enabled = false # property needs to be named like this for proper grouping

And be it.

@reduz

One possibility may be to make something like NOTIFICATION_ACTIVATED that is called when the node is enabled, so you can use it with NOTIFICATION_DISABLED and it would work as you suggest

I'm sorry again, but did you mean to say NOTIFICATION_DEACTIVATED?
NOTIFICATION_DISABLED as I understand isn't called when a node leaves the tree. If there's a new pair of callbacks that fire both when a node enters/leaves and getting enabled/disabled, that should solve the biggest problem with the current lifecycle. I'll just put all my init/uninit logic into those and encourage everyone to prefer them over ready and enter/exit_tree where possible so that we could have a more predictable behavior in shared assets
If we also address the inconsistencies of how process works for some built-in nodes that @KoBeWi mentioned (like cameras), and add a ConnectFlag for an option to prevent signals from calling methods on disabled nodes then I believe this will cover it all

To clear a few things up:

At first glance, I expect this feature to be a shortcut to set the Node’s process_mode to disabled and also turn off visibility in one click… So from a usability perspective, I would be confused about why this new feature isn’t modifying these properties.

node_active is an override, so regardless of the state of those 2 properties, an inactive node will never render or process. The shortcut aspect is just point 1. of the purpose behind this PR though indeed for me personally it is the most important.

Disabling active of a collider won't stop colliding either, or at least nothing in the code indicates so.

It does actually! Collision is disabled when process_mode is disabled and as a result an inactive node will not collider either. I demonstrated this here.

I think a simpler version of this PR that just disables processing and exposes this in the scene tree dock, while leaving visuals alone makes more sense.

But in that approach we lose point 1. which is to act as a shortcut for both properties. I know one extra click in the scene tree isn't exactly the end of the world but conceptually it seems a lot easier for users to just have to worry about node_active and basically never have to touch visibility. As @passivestar mentioned above I would have to think the more common use case is to disable a node completely and the fact that people are used to the visibility toggle is just a consequence of it being a part of Godot for so long. I wouldn't want to eliminate that workflow but as discussed in https://github.com/godotengine/godot-proposals/issues/7715 , we believe that in the long term this new property will simplify things if people use this in place of the other two.
Totally get that this is a big change and I don't want to presume any specific "correct" approach, but this was the way that made most sense while leaving everything else intact and adding some extra functionality for users to boot. If we were to go with the process override instead, it would definitely be an improvement to current situation in terms of workflow, but I feel like we'd miss out on a chance to rethink the system and make it even easier for newcomers. I also believe the concept of a universal disable is useful in its own right and makes the most sense for new lifecycle functionality. But those are just my thoughts and a reflection of the discussion that was happening in the proposal :)

Disabling processing effectively disables it in practice, node does nothing. No processing, no input, no physics (which you can decide whether you want it to make it static or just remove it from processing)
...
I think a simpler version of this PR that just disables processing and exposes this in the scene tree dock, while leaving visuals alone makes more sense.

To be fair as long as the lifecycle callbacks align with what we have here It would probably be fine to just have a toggle button for process mode.
That said I think this is still a good compromise between a universal toggle, and continuing to respect the individual separate toggles for more granularity
The one thing a process_mode toggle button in the scene view doesn't do, which I still think is valuable is visibility at the Node class level which this does. One of the best Godot features is that the Node class doesn't have a transform, but I have run into cases where the root of my scene is intentionally a Node because I don't want the scene have a transform/offset and I want to be able to load but fully disable the scene and all it's children, however since the root is a Node type, it's not possible. We could move visibility to Node, even though Node doesn't have any visuals, the fact that visibility affects children, would make it valuable even on the root node, and would benefit from being able to toggle visibility of a Node that we only know is of type Node and not need to check and cast to a Node2D or Node3D to toggle visibility.

If we also address the inconsistencies of how process works for some built-in nodes that KoBeWi mentioned (like cameras), and add a ConnectFlag for an option to prevent signals from calling methods on disabled nodes then I believe this will cover it all

Yeah I think any rendering-tangential nodes would probably need to be looked at how they are affected by process_mode like WorldEnvironment

As passivestar mentioned above I would have to think the more common use case is to disable a node completely and the fact that people are used to the visibility toggle is just a consequence of it being a part of Godot for so long.

It's anecdotal but when I posted about this PR on social media, the first response I got was "I always assumed the 'show/hide' status was basically it" and "I always assumed Show/Hide did just what Active does in Unity." But if you just search for things like "godot disable" you find a bunch of posts asking "how do I fully disable something in godot" and with that many that there must be at least a significant portion of users who expect there to be a straightforward checkbox to just "turn off" a node.

The one thing a process_mode toggle button in the scene view doesn't do, which I still think is valuable is visibility at the Node class level which this does.

Apologies for the double post but I really wanted to highlight this as well, there can often be "breaks" in the scene tree with plain Nodes instead of Node3D which can make it tricky to disable whole groups of nodes and you may need to add transform data (i.e. memory overhead) just to get a parent that has a visibility toggle.

We could move visibility to Node, even though Node doesn't have any visuals, the fact that visibility affects children, would make it valuable even on the root node, and would benefit from being able to toggle visibility of a Node that we only know is of type Node and not need to check and cast to a Node2D or Node3D to toggle visibility.

This would be one solution to the above but at the cost of breaking compatibility with the existing API. Hence in addition to the reasons above & your comment about thinking visibility is "active state", there should be no ambiguity with this new property :)

@RobProductions

But in that approach we lose point 1. which is to act as a shortcut for both properties. I know one extra click in the scene tree isn't exactly the end of the world but conceptually it seems a lot easier for users to just have to worry about node_active and basically never have to touch visibility.

Yes, I already expressed disagreement on this and explained on my comments why I don't like this idea.
I think having them separate makes more sense on how Godot works.

@RobProductions

But in that approach we lose point 1. which is to act as a shortcut for both properties. I know one extra click in the scene tree isn't exactly the end of the world but conceptually it seems a lot easier for users to just have to worry about node_active and basically never have to touch visibility.

Yes, I already expressed disagreement on this and explained on my comments why I don't like this idea.
I think having them separate makes more sense on how Godot works.

Appreciate you disagreeing, I do not and I think this is great 😇

Just want to further chime in and say that, as a developer who has never used Unity, I think this idea is fantastic! It would represent a major upgrade in power and convenience over how nodes are handled now.

I think for me it boils down to that at the end of the day, everything inherits from Node, and this treats Node in a way that is unambiguous, all nodes will have this property, there will never be a case where you have a reference to something that can't be toggled completely off since it lives at the root of all node types.
Sprite2D <- Node2D <- CanvasItem <- Node
DirectionalLight3D <- Light3D <- VisualInstance3D <- Node3D <- Node
etc.
Maybe under the hood they are treated differently, which is great and the goal of this toggle was to keep it that way while providing a convenience around, fully disabling a node at the root. This change tries to respect the differences of the inherited classes, but this adds the ability to change the state of the base Node class on or off in a universal way, and inherited members respect the value of the base class.
As mentioned before I also think it's fine if we want to treat them fully separately, and then have toggles for both, but I'd want to see a change that adds the separate toggles for things to the base Node due to the state of the parent's toggle affecting children, then we wouldn't need to have a single on/off toggle at the root.
@export var my_node : Node
func disable():
    my_node.visible = false # visible is present on the Node type
    my_node.process_enabled = false

This change would be for cases where the base Node is used as an organizational tool, but we still want to toggle something from the root.

@Snowdrama

As mentioned before I also think it's fine if we want to treat them fully separately, and then have toggles for both, but I'd want to see a change that adds the separate toggles for things to the base Node due to the state of the parent's toggle affecting children, then we wouldn't need to have a single on/off toggle at the root.

The nodes already have a process mode and this determines whether it is inherited or not towards children. The extra bool I mentioned would simply disable the node, so if children are set to inherit they will be disabled, otherwise they can be set to enable and unless you disable they will remain disabled.

This change would be for cases where the base Node is used as an organizational tool, but we still want to toggle something from the root.

Just use Node3D for organizing. Or Node2D in case of 2D scenes.

the process mode and visibility properties together achieve a similar effect and its good that they are separate to me. Adding a yet third state to coordinate both seems unnecessary and adding more confusion to a system that you have to learn anyway and it won't go away just because you add this state.

I don't agree, @reduz. There's a lot of behavior that occurs outside the process mode and the visibility properties. How many times there's something that I just want to deactivate, to toggle without having to delete an entire node leaf.

Having visibility and processing separately makes more sense in code than it does in the scene dock. More often than not you'll want to disable game entities completely, not just their visibility or their processing. More often than not I'll have to click both buttons

Actually you would be surprised that most of the time you don't want to do both and this is not a problem Godot users face often (as you can see it's been a decade, so it shouldn't surprise you this is not very requested).

Just because people aren't making a massive amount of noise about it doesn't mean it isn't an issue, or something that can be improved upon. I ran against it the first time I tried to seriously use Godot (finished making an enemy for my prototype, went "okay, let's move onto the next feature", set it to invisible, and I was then very confused and annoyed when the now invisible enemy was attacking me). This interrupted my flow state, as I now had to actually think about what to do about this problem, as opposed to just checking a single checkbox and forgetting it. I'm still frustrated that Godot doesn't behave this way regularly, and whenever it happens it makes me not want to use it. I have a very strong feeling that this might be more common of an experience than you think.
I'm trying to think of a time where I was making game content in the editor (not coding) and actually wanted to set the process and visibility mode as separate things. 99% of the time I want to set the node into one of two states:

Completely active.
Not active (Nothing runs, including any startup lifecycle callbacks)

If I need to switch to one of the other process modes (pausing for example), then that's done at runtime. I like that I have the option to control process/visibility separately at runtime for the cases where I'd need it, but a editor single checkbox solves almost any "game editor" use case that I've encountered in past decade that I've been a game developer. Making me click twice to fully disable a node instead of once just adds more work, which may sound ridiculous till you extrapolate out the number of times the users will be performing the action across the years that games take to develop (I personally enable/disable things very often and I think a lot of other users will too, given the option). There are absolutely valid design critiques of the Unity "active state" system, but I'm also genuinely struggling to think of a time where that system has caused me any actual massive headache.
It also wouldn't stop _ready() and _enter_tree() from being run. Passivestar had a very good point there and unless I'm mistaken, I don't think Reduz addressed it at all. Being able to easily stop these from happening is actually very useful, because otherwise you have to manually check for the process mode inside any given script where you'd want this to happen, which is just not reasonable. And again, you can't control what plugins do without modifying their code.
As far as being confusing to users, I'm pretty sure you could explain it with a one or two diagrams that outlines how the three variables effect the node's state, and how lifecycle callbacks get executed. It really does not come off as complicated to me from the PR description.
So far in this thread I haven't seen any concrete details on the specific technical issues that'll result from adding this one extra layer of state to the node system. It's not an exceedingly complex mechanism and seems fairly simple in implementation.
Reduz's core dispute seems to be that this conflicts with a core aspect of the engine's design (Process/Rendering are supposed to be kept separate). I don't personally see how adding one toggle that overrides both of these conflicts with that, but if that's the case then... yes. By making and supporting this PR, the users are implicitly saying that an aspect of the engine design does not actually account for a specific behavior that users want, and that this aspect of design should be expanded in a minor way to account for that said behavior. I think that's pretty reasonable.

Just adding support as another non-Unity user (and a less technically-inclined Godot user). Having a simple toggle that provides the peace of mind that a node and its children are fully disabled, including _ready() and _enter_tree() and the like, would be a lifesaver.
As of right now, it's needlessly difficult to implement (as far as I've been able to tell at least, so forgive me if I've missed something obvious). Creating a component to auto-delete its parent at runtime ends up having to worry about the scene tree order. Having to add code and checks to the _ready() or _enter_tree() methods of every single node that might need to be disabled is a huge waste of time, cluttering nodes that already have scripts and adding scripts to nodes that don't need them. A simple checkbox would be a wonderful solution, but I don't care what it is--I'd be fine digging through menus to get to it as long as it provides the certainty that the node is as good as nonexistent until I specifically ask for it to start existing sometime at runtime, and as long as it is considered the default, universal way to do it in Godot. (And that's generally ignoring the potential of its applicability to disabling @tool scripts and the like.)
Regarding the separation of Process/Rendering, I'm curious, how does adding a toggle that affects both fundamentally break this rule? There are already situations where changing one toggle in a node will automatically disable others iirc, so how does this do anything but simplify the user's interaction with those systems?

Just use Node3D for organizing. Or Node2D in case of 2D scenes.

Yes, but that's why I brought up:

you may need to add transform data (i.e. memory overhead) just to get a parent that has a visibility toggle

Not a huge increase in memory I imagine but it's possible this could add up in some projects and gives people the opportunity to optimize further. This is just a small technical advantage but conceptually/UX-wise I believe it can have a much bigger impact as we're hearing from the users chiming in on the thread (thank you!) and will ensure node type isn't even a consideration for this scenario...

Having a simple toggle that provides the peace of mind that a node and its children are fully disabled, including _ready() and _enter_tree() and the like, would be a lifesaver.

I want to clear up potential confusion on this, the toggle will not interfere with the way _ready() or _enter_tree() works. Instead the idea is that if you'd like to care about node_active, you can hook into 2 new lifecycle methods called _node_active() and _node_inactive() which are called when the node becomes active or inactive, including when it enters/exits the scene tree. So you can use these for initialization/cleanup instead of the other functions which remain the same as before. As we learned in the proposal, messing with ready() would have too many bad consequences so this solution was much better as it does not disrupt any existing workflow :)

I want to clear up potential confusion on this, the toggle will not interfere with the way _ready() or _enter_tree() works.

Ah, my bad. Based on various statements made during the discussion I thought that was implemented here. Regardless, being able to move the code from those methods to one that respects an in-editor toggle is a good enough solution to the issue, just one that requires some re-writing of a project to make fullest use of.

This is just a small style/nitpick but I would probably suggest alternative style for the "disabled" nodes (when they are disabled) in the tree list.
In the list of nodes, there are already few cases where the nodes are grayed out (e.g. uneditable child of an inherited scene). I feel that if we changed the style for the disabled node, it would be easier to tell why this node is not normal.
Suggested style: red name with strikethrough - I believe this would help stand out especially in a large scene with huge number of nodes in the list.
Also add filter support to the filter input with @disabled or something similar to display only disabled nodes.

@mrawlingst Good point, though I have to say red name and strikethrough is way too visually distracting for something like this that is meant to be used in place of previous toggles. I also believe that faded is already the best way to communicate it along with the (optional) scene tree checkboxes, though they could also receive some sort of faded treatment in certain situations like a child of inactive node for better clarity. The reason faded makes most sense to me is that is the exact same fade as process_mode being disabled, which is exactly what this toggle does and tries to convey. The same goes for the fade on the visibility toggle. It actually took no extra code to create the effect, just had to update it at the right time and that's because the specific fade colors are already associated with can_process being false and visible_in_tree being false. Hopefully that makes sense why UI-wise I think people will find this most familiar to the existing style, but I'm open to trying out other ideas if there are specific justifications!
For your note about filtering I like that idea a lot! I will look into that :)

Since there seems to be a lot of confusion about what this PR does and doesn't do (and what the proposal proposed and expectations from that) I think it'd be good to clear up those questions, like:

How does this affect different methods, notifications, and signals, like _ready, _process, etc.
How does this relate to the original proposal idea, which was to essentially be equivalent to removing the enode while not having to remove it, i.e. stopping all processing, both that which is affected by process_mode and that which isn't
How does this behave when loading a scene, does it prevent a node from entering the scene and interacting if disabled from the start?

How does this affect different methods, notifications, and signals, like _ready, _process, etc.

While a node is inactive, it will:

Still receive _ready, _enter_tree, and _exit_tree like normal
Not be "visible in tree", i.e. the visibility toggle is overridden to false
Act as though process_mode is set to disabled, which means it will...
Not run _process, _physics_process, or _input
Still receive all signals and notifications like normal
Still allow external scripts to run code in a script on this node directly, i.e. via direct function call
Not act as valid camera in 2D or 3D
Not collide with anything

Ultimately anything that was previously affected by process_mode or visible is now affected by this. The only special case I accounted for was cameras because they were previously not affected by . Though the CanvasLayer bug that @passivestar found has yet to be accounted for as well; I will fix that up shortly :)
The moment a node's active state changes, it will run:

NOTIFICATION_VISIBILITY_CHANGED notification
visibility_changed signal
NOTIFICATION_PAUSED or NOTIFICATION_UNPAUSED notification
NOTIFICATION_DISABLED or NOTIFICATION_ENABLED notification
NOTIFICATION_NODE_ACTIVE_CHANGED notification
node_active_changed signal
node_active_in_tree_changed signal
And the _node_active and _node_inactive lifecycle callbacks and their corresponding notifications

How does this relate to the original proposal idea, which was to essentially be equivalent to removing the enode while not having to remove it, i.e. stopping all processing, both that which is affected by process_mode and that which isn't

The proposal topic was aimed at creating 2 improvements:

Creating a faster/more convenient way to disable the visibility/processing of a node
Creating a more universal disable system that stops "all" node impact (some things cannot be accounted for) that is simple to use. Example quote from the original proposal description: "In the inspector view there will be a disable/deactivate checkbox. If this is checked the node becomes faded or another color in the scene view."

With the new property, features that were previously toggled via process_mode are now also turned off by node_active, and other features that we expect to be disabled when a node is "inactive" can now poll this property to disable themselves. The first example of this is the camera behavior. If there are other features that need the same treatment they can be added here or in a future PR, but crucially this aims to lay the groundwork for a more unified system that satisfies both points in the proposal.

How does this behave when loading a scene, does it prevent a node from entering the scene and interacting if disabled from the start?

You can still reparent, instantiate, and manipulate an inactive node without issue. A Node that enters the tree while inactive will still run _enter_tree and _ready as before but since it acts as though process_mode is disabled, it will not process/run code itself unless a signal or external script triggers something in it. As I mentioned above, future PRs could tie in signals to this system as well with a parameter or something like that but for now this is a good first step. Hopefully between this and the original PR description that communicates everything that this aims to do! Happy to clarify anything else if needed!

@RobProductions
what if there is one "checkbox" and that box can toggle between 4 states ( not in this order but you get the idea )
first nothing disabled

second visibility false

third everything disabled

fourth all process modes disabled

what if there is one "checkbox" and that box can toggle between 4 states ( not in this order but you get the idea )

Hi, we have discussed concepts like that heavily in the proposal and ultimately people found it too convoluted to use a multi-state icon for something like this. I'd have to agree, for both clarity and speed purposes, that it should be on or off for each property. For concerns about too many buttons in the scene tree, that's why there exists a setting to enable them and it is defaulted to false so that nobody will be bombarded with checkboxes when they first load it up :)
Some people in the proposal actually also preferred to see more buttons in the scene tree for operations like this as they found it useful. In the future we should look towards @Snowdrama 's idea of creating Blender-style icon filters to more easily manage user preferences:

oa

Alright, fair enought :D
What about the "right click" menu?

Some people in the proposal actually also preferred to see more buttons in the scene tree for operations like this as they found it useful.

In the proposal I did a mock up and I just recently updated the mock up using the gear icon that was posted in in reduz's first post about processing disable.

I also did a variant that moved these to the left side of the window that could be done in a future PR if it was something that people were interested in I know currently I don't think that's possible but I think it looks good.

Both of these also include a small transparency/fade change experiment that makes the icons of "inherited" disabled nodes darker to set them apart from the node that actually disabled them.
I also mocked up an icon change for disabled nodes similar to how the eye closes when clicked. The icon only has a has a single gear vs two gears(Symbolically the gear isn't being driven by another gear so it's not "processing")

But yeah I still think a good idea eventually might be to add Blender style toggles to the top to let the user choose if they want to see icons. Don't currently care about processing icons, You don't have to see them.

What about the "right click" menu?

Definitely a good idea for sure!

Some people in the proposal actually also preferred to see more buttons in the scene tree for operations like this as they found it useful.

In the proposal I did a mock up and I just recently updated the mock up using the gear icon that was posted in in reduz's first post about processing disable.
I also did a variant that moved these to the left side of the window that could be done in a future PR if it was something that people were interested in I know currently I don't think that's possible but I think it looks good.
Both of these also include a small transparency/fade change experiment that makes the icons of "inherited" disabled nodes darker to set them apart from the node that actually disabled them.
I also mocked up an icon change for disabled nodes similar to how the eye closes when clicked. The icon only has a has a single gear vs two gears(Symbolically the gear isn't being driven by another gear so it's not "processing")
But yeah I still think a good idea eventually might be to add Blender style toggles to the top to let the user choose if they want to see icons. Don't currently care about processing icons, You don't have to see them.

What about the "right click" menu?

Definitely a good idea for sure!

left side for the cog icon does look really nice in my opinion and makes more sense to me. the way I see it is the right side icons are mainly references of that node to bits of code and left side are controls of that node 👍

The icon ideas here are neat! But definitely out of scope for this PR; as I mentioned in the proposal discussion in order to put icons on the left it would require some sort of "leading button" feature for the scene tree that would likely be a PR on its own. Since there is no visibility option in the right click menu currently, that also seems like its own PR for the future. I also want to keep clarity and the intent of the new property intact and not confuse it with processing, so would prefer to leave it as a checkbox, though I'd be happy to investigate different stylings for it :)
I made 2 changes to the code: CanvasLayer is now working with node_active, see here with active on:

And with active off:

Though since it is implemented differently than Node3D (CanvasLayers by design are not supposed to cascade visibility from parent CanvasLayers) it's a little tricky to mesh that with the existing visibility field and you get a visual issue here where the eye thinks visible is false. Will take a bit more tinkering to get the visual quirk eliminated, the best way is probably to implement "visible in tree" equivalent here but without the parent cascade part. (The scene tree literally searches for that binding name to use the fade colors so it seems the most straightforward option)
Second change is stopping _node_active() from being called twice on initialization. If you set to inactive and then back to active in _ready it previously didn't know that it already sent the active callback, so it would do it again when the scene loads. With this change, that's no longer an issue since it now tracks when it has fired off the method! And lastly, if it was missed before I updated is_node_active_in_tree to use the "CanvasItem-like bool implementation" so that there is no more recursion 😄

The icon ideas here are neat! But definitely out of scope for this PR; as I mentioned in the proposal discussion in order to put icons on the left it would require some sort of "leading button" feature for the scene tree that would likely be a PR on its own.

100% I knew that the left side ones wouldn't happen in this for sure, the main one being the right side. For now I've deleted the left side mocks, in an attempt to not confuse things.

I also want to keep clarity and the intent of the new property intact and not confuse it with processing, so would prefer to leave it as a checkbox, though I'd be happy to investigate different stylings for it :)

My main reason for posting the mock was that it seemed that the only real pushback for node_active was that the checkbox combined visibility and processing together(which I don't mind personally)
To make up for me making things confusing here's a mock using checkboxes on the right, re-styled to use similar iconography as the existing icons including fading the children, mimicking visibility

A simple checkbox would be a wonderful solution, but I don't care what it is--I'd be fine digging through menus to get to it as long as it provides the certainty that the node is as good as nonexistent until I specifically ask for it to start existing sometime at runtime, and as long as it is considered the default, universal way to do it in Godot. (And that's generally ignoring the potential of its applicability to disabling @tool scripts and the like.)

I wonder if it would be valuable for this toggle to take the node out of the tree completely. Keeping it on an internal list owned by the node's parent so it can be easily re-added/deleted when the owner is deleted.
Currently taking a node out of the scene is a way to 100% disable them without a doubt, but you can only do it with cumbersome custom code and great care to avoid memory leaks. Providing a shortcut for it would achieve the effect this PR is going for (I think) while having less collision with the current process/visibility system.

I wonder if it would be valuable for this toggle to take the node out of the tree completely.
Personally, this really wouldn't be satisfactory for the feature set I'd want. Part of the whole idea behind this is that the node still exists in the tree, and if I really wanted to I could walk the hierarchy to find them and activate them at runtime.

After discussing with other contributors and community members, I opened a proposal with what is in my view a cleaner (more in line with how the engine works internally) solution to the original problem.
https://github.com/godotengine/godot-proposals/issues/10212
To me the bottom line of the discussion is that, if you want to disable nodes in the cleanest way possible, It's just not possible to do this in Godot while they remain in the scene tree, because the engine simply does not expect this to happen at several levels, so as suggested by @KoBeWi above, the proposal describes a different way to achieve exactly the same.


chore: revert add auto-label for v2 PRs (#4505)

This reverts commit 2e1ffe8cbb04a38844c7711412290f721625774a.
https://coveord.atlassian.net/browse/KIT-3661

Workflow is disabled let's fix instead

@louis-bompart  This action should not be in the master branch. It should be in v2. We can't fix it here. Every PR based on v2 won't have access to that action...

Workflow is disabled let's fix instead

@louis-bompart  This action should not be in the master branch. It should be in v2. We can't fix it here. Every PR based on v2 won't have access to that action...

I don't think so.
I think instead this is due to

To ensure repository security, branches with names that match certain patterns (such as those which look similar to SHAs) may not trigger workflows with the pull_request_target event.
From https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request_target

Workflow is disabled let's fix instead

@louis-bompart  This action should not be in the master branch. It should be in v2. We can't fix it here. Every PR based on v2 won't have access to that action...

I don't think so. I think instead this is due to

To ensure repository security, branches with names that match certain patterns (such as those which look similar to SHAs) may not trigger workflows with the pull_request_target event.
From https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request_target

proof it does not work. the v2 branch has no access to that action. https://github.com/coveo/ui-kit/pull/4544


I would suggest feat: add profile scope in OIDC token request


DocumentDock Collapses when it shouldn't

In the sample project Notepad the FilesDocumentDock have its IsCollapsable set to false but still is collapses after moving a docked window.
https://github.com/user-attachments/assets/823803f5-5279-4379-abc3-d68573c443f8

I use the following workaround
public class DockFactory : Factory
{
    /// <summary>
    /// Prevents closing dockables that shouldn't be closed
    /// </summary>
    /// <param name="dockable"></param>
    /// <param name="collapse"></param>
    public override void RemoveDockable(IDockable dockable, bool collapse)
    {
        if (!dockable.CanClose)
        {
            return;
        }

        base.RemoveDockable(dockable, collapse);
    }
}


Auto-inject the IP tag for operator-injected agent

Fixes #865
Signed-off-by: Ruben Vargas<EMAIL_ADDRESS>

@TBBle, @objectiser : what's the verdict then?

I think the agreement was to merge as-is, unless you have changed your mind?

No, just wanted to confirm before merging :-)


Tessellation is misspelled as 'tesselation'

The RenderSystem.RENDER_THREAD_TESSELATOR field and RenderSystem.renderThreadTesselator method both misspell 'tesselation'. While the crash report message makes this same mistake, other Yarn names, such as the Tessellator class, fix this typo.

Those are not obfuscated, can yarn actually fix them?


Included forth PR instructions

Description

Included forth PR description in the end of the document following #417 instructions.

Approved :)


require function is used in a way in which dependencies cannot be statically extracted

I added console.log(require.ensure) to my code and it resulted in thousands of error lines from webpack. Had to increase my tmux scrollback to 40K lines to see what happened.
[...]
WARNING in ./src/routes.js
Critical dependencies:
158:18-25 require function is used in a way in which dependencies cannot be statically extracted
 @ ./src/routes.js 158:18-25

WARNING in ./src/containers/Admin/TODO.md
Module parse failed: /Users/olalonde/code/project/src/containers/Admin/TODO.md Unexpected token (1:13)
You may need an appropriate loader to handle this file type.

[...]

Not sure if it's really a bug but would have been nice if that message had been isolated from all the subsequent thousands of error lines that are really irrelevant.

This is fixed in webpack@2

with webpack@2, it's reproduced again.
function getAsyncComponent(path, chunkname) {
  return function(nextState, cb) {
    require.ensure([], function(require) {
      cb(null, require(path).default)
    }, chunkname)
  }
}

const Routes = (
  <Router history={browserHistory}>
    <Route path='/' getComponent ={ getAsyncComponent('./App.jsx','asyncApp') }>
      <IndexRoute component ={ Home} />
      <Route path='/hello' component = {Hello} />
      <Route path='author' component = {AuthorList}>
        <Route path= ':id' component = {Author} />
      </Route>
    </Route>
  </Router>

)

export default Routes;

@minnaq it indeed is being used in a way in which dependencies cannot be statically extracted.
require.ensure([] is asking for webpack to load 0 modules (???), but more importantly, the require(path) is a require of a free variable with no context. Webpack doesn't go as far as doing program flow analysis to find out that your getAsyncComponent is only called with './App.jsx' with chunkname asyncApp.

@Kovensky

require.ensure([] is asking for webpack to load 0 modules (???)

That part seems to be supported. Search this page for []. Although I can't find any information on how that works.

Is it possible to get webpack to ignore these errors? Then allow the amd-plugin that builds for the runtime to find bundles that you package via separate webpack configs ie. i18n
A more complete example of https://github.com/webpack/i18n-webpack-plugin would be helpful here

same issue. How to solve this? Thanks.

How this one be closed ?

The short answer is that webpack statically analyzes your require statements explained here: https://webpack.github.io/docs/context.html
Fixing this is different for every case. If you post some code somebody should be able to point you in the right direction. https://gitter.im/webpack/webpack

@drewwells the real issue was that thousands of lines were printed making it hard to find out what the issue was

I understand there was a specific start to this thread, but the title indicates a more general issue that people find via Google searches. This being the use of variables in require() calls. It may help to change the title or open a new issue about console.log() if its desired to fix that. I don't think that particular bug will be addressed, since require.ensure is documented already: https://webpack.github.io/docs/code-splitting.html#commonjs-require-ensure

I'm getting this error with this line:
const broquire = require("broquire")(require);

My code is:
 if (configs.renderingConfig && configs.renderingConfig.codeSyntaxHighlighting) {
         require.ensure([], () => {
                const theme = configs.renderingConfig.highlightingTheme || 'default';
                window.hljs = require('highlight.js');
                require(`highlight.js/styles/${theme}.css`);
         }, 'highlight');
  }

There is the same warning in terminal

require function is used in a way in which dependencies cannot be statically extracted

And there is also two error in browser

Loading chunk 0 failed.
at HTMLScriptElement.onScriptComplete

vendor.js?v=20170309:92 Uncaught (in promise) Error: Loading chunk 0 failed.
at HTMLScriptElement.onScriptComplete

I get the same error for typedjson-npm.
WARNING in ./~/typedjson-npm/js/typed-json.js
25:24-31 Critical dependency: require function is used in a way in which dependencies cannot be statically extracted.

My problem was solved by making following change -
FROM
const moduleName = 'moduleName';

function getComponent(location, cb) {
  require.ensure([], require => {
    cb(null, require('./components'));
  }, moduleName);
}

TO
function getComponent(location, cb) {
  require.ensure([], require => {
    cb(null, require('./components'));
  }, 'moduleName');
}

i.e, avoiding the use of a const variable for the string 'moduleName'.
Don't know the reason though. :|

Using typeof require.context generates warnings as well.

Same here. @storybooks/storybook config goes like this;
const req = require.context("../stories", true, /.stories.js$/);
function loadStories() {
  req.keys().forEach((filename) => req(filename));
}

configure(loadStories, module);

Replacing line 1 with;
const PATH = resolve("..", "stories");
const req = require.context(PATH, true, /.stories.js$/);

errors (warns?) with

Critical dependency: require function is used in a way in which dependencies cannot be statically
extracted

Using<EMAIL_ADDRESS>

That is because the code was changed from calling require.context in a way that was analyzable into a way that isn't. Webpack doesn't know what your arbitrary "resolve" function returns, or that PATH is immutable (if you compile your code to ES5)

@Kovensky
From what I understand, this warning means the dependencies are not statically analyzable, and thus cannot be tree-shaken. Is this correct?
Is there anything else I should be aware of?
If I weren't compiling down to ES5, would webpack figure out that PATH is immutable?

The bigger problem here is that webpack doesn't know what the result of resolve is. It's just a random user function that can do anything at runtime.
This is also not about tree-shaking, this is about knowing what to bundle in the first place. If webpack can't see that you're trying to look into the ../stories directory via simple string parsing, it doesn't know that it needs to put the files in ../stories in a context module.

@sokra this is reproduced with<EMAIL_ADDRESS>as well.

@jony89 what is your webpack-dev-server's version?  try to upgrade to 2.9.7

Im using https://github.com/biesbjerg/ngx-translate-extract and get this error when using marker function to extract strings :(
webpack 3.11.0

@senyaak Submit an issue to that repo

@montogeek this is a webpack issue...

In case anyone else comes across this - I got this error because I was using "module": "umd" in my tsconfig.json. The solution was to use "module": "commonjs" instead - you can still get umd output by using libraryTarget: "umd" in webpack.config.js.

@aj-r  it's work

You can get this error if you accidentally import something from /@angular/compiler instead of /@angular/core. With auto-import this can happen easily.
For example this just happened to me when I used ChangeDetectionStrategy and VSCode suggested the compiler package - and I accepted it without realizing.


added instructions to pip install missing dependencies

Thanks for contributing a pull request! Please make sure you have read the
contribution guidelines
before submitting.
Please be aware that we are a loose team of volunteers so patience is
necessary. Assistance handling other issues is very welcome. We value
all user contributions, no matter how minor they are. If we are slow to
review, either the pull request needs some benchmarking, tinkering,
convincing, etc. or more likely the reviewers are simply busy. In either
case, we ask for your understanding during the review process.
Again, thanks for contributing!
Reference issue
10562
What does this implement/fix?
Made revisions to _soft_import() in mne.utils.check to give more verbose instructions to install a missing MNE optional dependency.
I also added a line to _get_3d_backend in mne.viz.backends.renderer to give more verbose pip install instructions in the error message that is returned if both MNE Valid 3D backends (pyvistaqt or ipywidgets for notebook) are missing.. I've run into this missing 3D backend dependency error message when running mne.viz.plot_alignments()
Additional information
Any additional information you think is important.

Thanks @scott-huberty !

No problem, thanks all for the help!


Chain proteinfold output to msa input

Description of feature
Chain proteinfold output to msa input

Solved in #176


Default shadow bias is too low for SpotLights

Same problem as #12028 but gonna post this since that thread(?) seems to be quite dead.
Godot version:
3.0 stable
OS/device including version:
Windows 7 x64 Professional with 16GB of RAM
Intel HD 4000 with newest drivers (Version: <IP_ADDRESS>85 Date: 1/3/2018)
Issue description:

Any spotlight with shadows enabled causes stripes to appear on the lighting.
Both spotlights in the image above are at default settings, except for the one with shadows on.

Zoomed up:

Directional light with "Max Distance" of over 500 starts to show same issues as spotlights
Max Distance set at 500. Stripes are barely visible but are there.

This effect maxes out at around 1000 which doesn't change no matter high you set the Max Distance at.

Minimal reproduction project:

Two scenes are included; one with spotlights and one with a directional light.
shadowbug.zip

Young's double slit experiment

In spotlight, this is the limit of shadow bias, if light is parallel to the surface there is no way to get rid of the strips (increase the bias to 1 and rotate it -0.5 degree on X and stripes start to disappear), not sure if is a bias bug, need a hack to work in this setup or what.
The directional light issue may be a different one, related to intel gpu because I do not see it with nvidia proprietary on linux (search issues mentioning intel graphics).

I still think someone with a bit more experience should take a look at the
shadow code.. I have the feeling I am missing something else to avoid these
On Feb 18, 2018 21:58, "eon-s"<EMAIL_ADDRESS>wrote:

In spotlight, this is the limit of shadow bias, if light is parallel to
the surface there is no way to get rid of the strips (increase the bias to
1 and rotate it -0.5 degree on X and stripes start to disappear), not sure
if is a bias bug, need a hack to work in this setup or what.
The directional light issue may be a different one, related to intel gpu
because I do not see it with nvidia proprietary on linux (search issues
mentioning intel graphics).
—
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/16787#issuecomment-366565122,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2_onsKviN-3_oMRT6pYjYfgDsD_Gks5tWMcagaJpZM4SJgCB
.

This is a normal part of shadowmapping called "shadow acne", it's caused the same way as z-fighting. This is what the bias values are for: so devs can tweak individual lights in their projects to minimize it. Reduce your shadow distance to the absolute lowest possible value you can get away with in your scene, and tweak the bias/contact values. Another tip is to enable reverse culling, which shadows using backfaces instead of front-faces.
The tricky part is making sure your shadows are properly casting (as well as one can manage) from objects/surfaces that are extremely close to shadowed surfaces - because increasing bias to differentiate between a surface and its own shadow also causes objects near that surface to lose their shadow if they're closer than the bias value (aka 'peter-panning').

I don't think this is a bug, but will see how it remains in 3.2

In just releaser Godot 3.1 stable version I noticed that too, strange thing is that I didn't notice that in the first alphas. Has some default value changed?

I could reproduce the issue with spotlights in the MRP in the current master branch, but not with directional lights.

With directional lights, I can see the strips when the camera is far from the surface (almost max zoom out on the editor).
With the spotlights, the strips disappear when I enable the "reverse cull face" option on shadow section (I have no idea of what it does because there is no description).
Using Godot 3.2b, AMD R5.

With directional lights, I can see the strips when the camera is far from the surface (almost max zoom out on the editor).

This is due to shadow bias. You can increase Normal Bias or Bias Split Scale (the latter will only impact far-away splits, not the closest split).

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


building modules without -b flag fails

While fiddling around with a new sublime text build system for Transcrypt I noticed that repeatedly building the same project fails if the project includes a submodule.  The first run is fine but subsequent runs will fail with this error:
   Error while compiling (offending file last):
	File '/Users/stevet/prj/bab/bab.py', line None, at import of:
	File '/Users/stevet/prj/bab/game.py', line None, at import of:
	File '/Users/stevet/prj/bab/org/babylonjs/api.py', line 0, namely:

	'ascii' codec can't decode byte 0xc3 in position 3221912: ordinal not in range(128)

I'm pretty sure this is because Transcrypt is re-writing the file in the compiler (probably at Module.parse(), line 420 and not checking to see if the file is already UTF-8

I've tried to reproduce this with:
Transcrypt 3.6.101 release, windows
Transcrypt 3.6.101 master, newest commit, windows
Transcrypt 3.6.101 master, newest commit, linux
I've written a small test program with a submodule:
file test.py:

from test_sub import f

f ()

file test_sub.py:
def f ():
    print ('test')

I've also tried the autotest, which contains several submodules.
And I've tried pysteroids, which contains several submodules.
All without the -b switch, and with and without minification.
Unfortunately I have not yet succeeded in reproducting this error.
Are  you developing on Windows or on Linux?
Can you supply me with a minimal example to reproduce this?
Kind regards
Jacques

Try checking the things mentioned in this issue.

The module is mostly a thin wrapper around a js library (in this case, Babylon.js), and evidently that file is all in US-ASCII though my code is all in UTF-8

Here's the repo that generates the issue on OSX:  git@github.com:theodox/bab.git
I can't repro the problem on Windows however.

The whole logic of building / making and dependencies has been refactored.
Does this problem still exist on OSX?


Spaces indentation lost

Hi, there is a mystery somewhere:
When previewing a simple HTML file https://emgithub.com/pajasevi/CSSnowflakes/blob/master/snippet.html everything looks fine,
But when I try to embed it, I lose all indentation. There is nothing but the <script>, no CSS, etc.

Do you reproduce?

Yes but if you enclose it inside regular <!DOCTYPE html> <html>... <body> </body></html> it should looks normal.
(Note the <!DOCTYPE html> is necessory. Refer: https://stackoverflow.com/questions/6076432/why-do-i-need-a-doctype-what-does-it-do )


Trained the model to output preventive measures as well

Pull Request: Enhanced Threat Analysis with Preventive Measures
Description
This pull request introduces enhancements to our threat analysis capabilities by training our AI model to provide not only threat analysis but also actionable preventive measures. This improvement aims to empower our users with more comprehensive security insights.
Changes Made

Updated the AI model to include preventive measures in the threat analysis.
Modified the diagram.py class to parse preventive measures from the JSON input.
Extended the DiagramHandler class to incorporate preventive measures into the generated sentences.

How to Test
To test the enhanced threat analysis and preventive measures functionality:

Clone this branch locally.
Run the application.
Use the provided JSON file as input to generate threat analysis and preventive measures.
Verify that the preventive measures are included in the generated sentences.

Related Issues
FIXES #1
Screenshots
Here is a screenshot attached of the Prompt

Hi sir, I am a beginner has done my best to contribute to this repository and I intend to do more such contributions as well as learn more about artificial intelligence. Therefore I request you to please review the changes and provide the PR with "HACKTOBERFEST-ACCEPTED" label that will not only motivate me to do more such contributions but will also help me to do more on the good repositories like this one
Therefore I request you to please provide the "HACKTOBERFEST-ACCEPTED" label
All other tasks given in the Contributing.md has been done from my side!
Thank You!
Varun

Greetings @LuizBoina
I am seeing that my pull request has been accepted successfully. With Due respect sir, it would be great of you to leave a " hacktoberfest-accepted" label on the PR or leave an approving review and I would love to get the label as hactoberfest doesn't count the PR until one of the previous requests has been done by the maintainer of REPO.
Thank You!
Varun

No problem, is this tag enough?

Absolutely sir, Thank you so much
I look forward to contribute more to this project as I want to learn more and make this model more interactive?
one little question? is the repo applicable for hactober-fest again if I contribute again for a new issue not at all related to the previous issue?

I appreciate your enthusiasm. Answering your question, I don't since this is my first participation on hacktoberfest event. If you have another idea to contribute to the project, make a pr and we'll see if it counts again ;D


Error: No PostCSS Config found in node_modules/...

"postcss-loader": "^2.0.6"
"webpack": "^2.2.0"
When a file from "node_modules/my_module/src/file.js" has a:
import 'react-infinite-calendar/styles.css'
I get this error:

my postcss.config.js:
module.exports = {     plugins: [         require('autoprefixer')({ /* ...options */ })     ] }
and my webpack.config.js

however when i add the inline config for postcss-loader it works:

so i think postcss-loader is not working with my postcss.config.js.
Thanks for advanced!

Where is your postcss.config.js located in the file tree? Could you show tree $PROJECT please. Config lookup starts from dirname(file) upwards by default and something like e.g
|– node_modules
| |– package
| | |– style.css
|
|– postcss.config.js
|– webpack.config.js

should normally work.
Otherwise either set Plugins/Options directly webpack.config.js or provide the config.path
webpack.config.js
{
  loader: 'postcss-loader',
  options: {
    config: {
      path: 'path/to/postcss.config.js'
    }
  }
}

@michael-ciniawsky yep, i have my postcss.config.js in the root directory

Could you show the file where you import/require the component style + postcss.config.js + webpack.config.js. Do you run webpack via gulp ? Any possibility that postcss-load-config would need to to move the file tree downwards during config lookup, starting from dirname(file) ?

@michael-ciniawsky
we create our a custom node-lib

in this file we have, "react-infinite-calendar" is a node_module:

webpack.config.js
https://gist.github.com/GiancarlosIO/63044ca1ed3e3fb5d8a5421412125290
and we run the webpack with "yarn watch":
"watch": "ENV=development webpack --watch --progress",

using this solve my problem:
config: {        path: 'path/to/postcss.config.js'      }
so I'll close this i think.


ci: update actions and golangci-lint

This fixes failing CI.
Changes:

update versions for actions/checkout, actions/setup-go
remove unneeded actions/cache because actions/setup-go has caching
update golangci-lint to the latest v1.62.0, it's compatible with Go 1.23
add git diff --exit-code after make because go fmt ./... may change files, and we should detect this and fail pipeline

Thanks for your contribution


black twitter icon in nav bar

I think it could look more cohesive in black. I also think black is supposed to be the default so not clear why it's in blue.

Does it work for you? I tried this locally with the Inspector, and it didn't seem to have any affect.
This does appear to be what the FontAwesome docs do on their example site though. Perhaps we have an older version of FontAwesome?

I wasn't sure how to test honestly & I'm also wondering if it's a version thing cause the default icons are black

There's a build in the CI here you can check.

So figured out builds #28 (thanks!) and yes the fab prefix is for v5 of font awesome https://fontawesome.com/v5/icons/twitter-square?s=brands


Enable plain merge in enabled_merge_buttons

In some cases, such as a release version, we will pick some
commits, then do a PR review, and then merge the commits into
the branch. In this case, we want to use plain merge to keep
the info of each commit instead of using squash-merge.
Or in some refactoring PRs, we can separate code moves (rename)
and actual changes into different commits. These single commits
we want to keep the commit message and doing a plain merge.
In this way, when tracking changes, we can only focus on actual
changes without being affected by meaningless diffs.
When enabled, we can control it (when we are doing merge, usually
squash is used, and in some cases we need to keep commits we use merge).
That is, the choice of squash or merge is the responsibility of the
person for merging the PR.
See #1622 for more discussion on release part.

hope to get your approval or comments :)

@tisonkun @PragmaTwice Does this sound good to you? with the merge button would also make the release process more smooth.

if I remember correctly, rebase merge in github will change the date of those commits to the current date? if that's the case, i would like to use merge to keep those commits with the truest commit time

if I remember correctly, rebase merge in github will change the date of those commits to the current date? if that's the case, i would like to use merge to keep those commits with the truest commit time

When you do cherry-pick, the date already becomes the pick date instead of the original commit. I don't think the date is significant.
And I check that rebase and merge won't change the commit date. (But it's the picked date, not the original commit date)

ok, as long as the author date is not changing, i am ok with that.
you are right, when doing pick, the commit date is changing (but the author time will not changing, i am seeing the author date in the default format in my PC, and the github seem to show the commit date by default, so it cause me some confusions)
i want mention that the another (or the only one) benefit of plain merge is that we can have a merge commit that associate the target PR, but it doesn't seem to matter in the release part. (But it does have a use case for sure)
i am changing the PR to enable the rebase-merge, for the release part.
thanks for the confirming btw


Heartbeat Refactor

Rename for consistency heartbeat.py > rp_ping.py
Proposed changes:

Move ping URL constructor completely out of worker_state and into rp_ping

We can leave worker_state as the source where jobs currently in progress will be stored for now.

Included in this refactor is job management, from a single job to a job list.


Provide RequestType in error data from HttpPlugin.

Closes #1253

Updated!

Looks good to me. Honestly, I probably should have done those changes to the unit tests while changing them for Fetch support.

Thanks for the review guys


On the Mentor Details and Mentee Details pages, split feedback form and details since both of them are on the same page

Let the mentor and mentee details be on that page and remove feedback form and put it as an option in the dropdown menu of the 'Me' tab in the navbar

Do you mean

Put feedback on one page, and ratings on another, and keep the mentor details separate as well (i.e. create 3 separate html pages)
OR
Put feedback on one page, and ratings + mentor details on another (i.e. maintain the 2 separate html pages)???
Might need to clarify this.

@yayalu We need to separate the Feedback form and the Mentor/Mentee details. Currently they are on the same page. Two ways to do this are:

Make two separate HTML pages, one for each
Let the Mentor/Mentee details page be where it is and move the Feedback Form to the Me Tab in the navbar as in make it an option in the dropdown menu of the Me tab

I have attached a screenshot for reference for option 2


Add support for longer Ember version strings

Ember version "0.1.11" was being sliced down to "0.1.1"
Added support for 2 more characters and trimmed off any trailing whitespace.

Thank you.


Allow multiple local rate limit configurations per route or virtual host

Title: Allow setting multiple local rate limit configurations per route or virtual host
Description:
It is useful to define rate limits for a few resolutions, for instance 50 requests/second and 1000 requests/minute for the same route or virtual host.
The global rate limiting API allows multiple rate limit configurations per route or virtual host.
The local rate limiting API, however, only allows a single local rate limits configuration.
Using Istio 1.8.1 + Envoy 1.16.1, I am only able to effectively define one local rate limit configuration per route or virtual host. Since I need to define two local rate limit resolutions, I am going around this limitation by defining one token bucket configuration for the inbound virtual host, e.g. 50 requests/second, and another token bucket configuration for the outbound virtual host, e.g 1000 requests/second. If I needed to set up more than two local rate limit resolutions, I wouldn't be able to.

I think this is a reasonable request. There are now more options available via https://github.com/envoyproxy/envoy/pull/14588 but I don't think it's possible yet to hit multiple limits. cc @kyessenov

I think this is a reasonable request. There are now more options available via https://github.com/envoyproxy/envoy/pull/14588 but I don't think it's possible yet to hit multiple limits. cc @kyessenov

Yeah, it's only possible with descriptors. I guess we could add route name / vhost name as another rate limit action as a workaround.

Yeah, it's only possible with descriptors. I guess we could add route name / vhost name as another rate limit action as a workaround.

it would be useful to allow multiple match configurations in the same time as well. I'm trying to apply rate for all requests as well as different rate for a specific header, where exhaustion of the overall bucket should stop the more specific match as well, without success.
the stage property in the https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-msg-config-route-v3-ratelimit
cannot be used as the typed_per_filter_config on route is map with the filter name as key and the stage is directly on https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/local_ratelimit/v3/local_rate_limit.proto#envoy-v3-api-msg-extensions-filters-http-local-ratelimit-v3-localratelimit in the value
trying to apply 2 filters with different names seems to result in one of them being ignored
this is using istio 1.10.2/envoy 1.18.2

I think we need API re-work for local rate limit to achieve this. There are several possible approaches:

Associate the stage with descriptors in the local rate limit filter config. Then we can have multiple rate limits for different stages work independently with descriptors. It might be worth generalizing the default rate limit for different stages, too.
Ensure that the local rate limit can be instantiated multiple times. From the first glance, we'd need to allow lookup of typed_per_filter_config by the extension name rather than extension type.
Relax the matching of descriptors to actions in the local rate limit. The algorithm iterates over rate limits and picks the first full match against the descriptors. We'd want to continue iteration and verify multiple buckets simultaneously. Perhaps, we could add fallthrough boolean to descriptors that indicates that instructs that matching should continue.

Thoughts on API design from @envoyproxy/api-shepherds are welcome here.

(3) sounds like the best option to me, though I haven't fully wrapped my head around (1).

Re: (2) we should solve that problem anyway. I think this is leftover tech debt from when filters were identified by their name strings as types.

Yeah, we do need to solve (2) anyway.  For context, see #12274.

(Yes agreed on solving (2) additionally)

I agree that (2) has wider benefits and satisfies the needs of two local rate limit. There's probably some space for performance optimizations to avoid multiple computations of rate limit descriptors from two instances of the filter. Do you think it's worth moving rate limit definitions from VH/route to filter config as well?

Do you think it's worth moving rate limit definitions from VH/route to filter config as well?

I thought this was already done? Don't we already use typed filter config?

The typed filter config supplies descriptors with buckets. But rate limit actions are defined per route itself. So there's no scoping of rate limit actions to individual instances of rate limit filter (local or global).

The typed filter config supplies descriptors with buckets. But rate limit actions are defined per route itself. So there's no scoping of rate limit actions to individual instances of rate limit filter (local or global).

Oh hmm, sorry I thought we had cleaned this up by now. Yes, this is just long ago legacy that should be cleaned up. I think all rate limit stuff should be removed from route and moved into typed filter config. If we do that along with (2) that would be a nice way of handling this I agree. (CORS is in a similar situation and has a tracking issue, I just thought rate limit was already done. I guess not.)

I'm working on RateLimit implementation in gRPC. I just was looking into "special handling" we'd have to do to make RateLimit filter work with its config fragmented into VirtualHost.rate_limits/RouteAction.rate_limits, and HttpFilter.typed_config.
Getting this cleanup done will be a great help, and will prevent a lot of temporary code/tech debt.
cc @yanavlasov

Tell me if there is any workaround to specify two local rate limits?

@nikolasj depends what do you need . there was relatively recent change where multiple buckets matching is supported.
see https://github.com/envoyproxy/envoy/pull/20869 an related https://github.com/envoyproxy/envoy/pull/25139

@jcetkov I need to specify two local rate limits for url/path. one limit, 3 requests per second. the second limit is 30 requests per minute. For both of these limits to work.
Can it be done? It seemed to me that no. If not, where can I see an example of how to do this?

that would be trickier, as you can't have 2 descriptors with the same value and if you try to have 2 actions with the same header_name but different descriptor_key it outright doesn't work.
I think you can achieve this by having a route per path with the main bucket at 3/s and a descriptor for the same path at 30/minute
something like this: (I was running this in the docker with a simple http listener on 8086, modify to your needs)
static_resources:
  listeners:
    - name: main
      address:
        socket_address:
          address: <IP_ADDRESS>
          port_value: 8888
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: ingress_http
                codec_type: auto
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: local_service
                      domains:
                        - "*"
                      routes:
                        - match:
                            prefix: "/foo"
                          route:
                            rate_limits:
                              - stage: 0
                                actions:
                                  - request_headers:
                                      header_name: :path
                                      descriptor_key: path
                            cluster: ext_web_service
                          typed_per_filter_config:
                            envoy.filters.http.local_ratelimit:
                              "@type": type.googleapis.com/udpa.type.v1.TypedStruct
                              type_url: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
                              value:
                                stat_prefix: http_local_rate_limiter
                                token_bucket:
                                  max_tokens: 3
                                  tokens_per_fill: 3
                                  fill_interval: 1s
                                filter_enabled:
                                  runtime_key: local_rate_limit_enabled
                                  default_value:
                                    numerator: 100
                                    denominator: HUNDRED
                                filter_enforced:
                                  runtime_key: local_rate_limit_enforced
                                  default_value:
                                    numerator: 100
                                    denominator: HUNDRED
                                response_headers_to_add:
                                  - append: false
                                    header:
                                      key: x-local-rate-limit
                                      value: 'true'
                                descriptors:
                                  - entries:
                                      - key: path
                                        value: /foo
                                    token_bucket:
                                      max_tokens: 30
                                      tokens_per_fill: 30
                                      fill_interval: 60s

                access_log:
                - name: envoy.access_loggers.file
                  typed_config:
                    "@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
                    format: "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %RESPONSE_FLAGS% \"%DYNAMIC_METADATA(istio.mixer:status)%\" \"%UPSTREAM_TRANSPORT_FAILURE_REASON%\" %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% \"%REQ(X-FORWARDED-FOR)%\" \"%REQ(USER-AGENT)%\" \"%REQ(X-REQUEST-ID)%\" \"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\" %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%\n"
                    path: /dev/stdout
                http_filters:
                  - name: envoy.filters.http.local_ratelimit
                    typed_config:
                      "@type": type.googleapis.com/udpa.type.v1.TypedStruct
                      type_url: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
                      value:
                        stat_prefix: http_local_rate_limiter
                  - name: envoy.filters.http.router
                    typed_config:
                      "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
  clusters:
    - name: ext_web_service
      connect_timeout: 10s
      type: STATIC
      lb_policy: round_robin
      load_assignment:
        cluster_name: ext_web_service
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: <IP_ADDRESS>
                      port_value: 8086

now you are talking about istio specifics, which is a bit out of scope here. you applied it to all routes in envoy with this. You'd have to have a virtual service matching your path (to have a corresponding route in envoy) and have a match rule in your envoy filter to only apply to given route. you can check :15000/config_dump in your pods to see how the effective envoy configuration looks.

it is very possible. you also missed the part of the configuration at the route level where the descriptor action is defined.
 rate_limits:
                              - stage: 0
                                actions:
                                  - request_headers:
                                      header_name: :path
                                      descriptor_key: path

but you are also applying the default bucket with 3/s to everything everywhere. If you make that big enough and have the descriptors for what you want, it works quite nicely. you were however asking for workaround for 2 rates on the same match - and as I said, for that you'd have to have the specific route first and then envoyfilter just that specific route using the route match https://istio.io/latest/docs/reference/config/networking/envoy-filter/#EnvoyFilter-RouteConfigurationMatch-RouteMatch
(to get effectively to the config I posted above)
but for second time, this issue is about envoy capability, not about flexibility with which you can configure it in istio...

@jcetkov Thanks for answers. Tried different options, but it doesn't work. I'm missing something.
Can we contact you separately and ask just a couple of questions? My mail is<EMAIL_ADDRESS>tg: https://t.me/Nikolay_samsonov

Hi, is there a way to disable the default token bucket when using the per-route envoy.filters.http.local_ratelimit? In the docs, it mentions that if there are no matching descriptor entries, the default token bucket is used. I want to apply rate limiting to requests with a specific header, and I only have one route in the route_config.
I could make the default token bucket big enough so that all other requests are allowed; however, I was wondering if there is a way to have the descriptor token bucket only and not the default token bucket so that requests not matching descriptors are not subjected to any rate limiting.
route_config:
  name: local_route
  virtual_hosts:
    - name: local_service
      domains: ["*"]
      routes:
        - match: {prefix: "/"}
          route:
            cluster: service_protected_by_rate_limit
            rate_limits:
              - actions:
                  - request_headers:
                      header_name: "my-header"
                      descriptor_key: my_header
          typed_per_filter_config:
            envoy.filters.http.local_ratelimit:
              "@type": type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
              stat_prefix: test
              token_bucket: # is it possibly to not have this applied?
                max_tokens: 1000
                tokens_per_fill: 1000
                fill_interval: 60s
              filter_enabled:
                runtime_key: test_enabled
                default_value:
                  numerator: 100
                  denominator: HUNDRED
              filter_enforced:
                runtime_key: test_enforced
                default_value:
                  numerator: 100
                  denominator: HUNDRED
              response_headers_to_add:
                - append_action: OVERWRITE_IF_EXISTS_OR_ADD
                  header:
                    key: x-test-rate-limit
                    value: 'true'
              descriptors:
                - entries:
                    - key: my_header
                      value: somevalue
                  token_bucket:
                    max_tokens: 10
                    tokens_per_fill: 10
                    fill_interval: 60s

no, the refill timer works on the default bucket and the descriptor buckets just ride along. make the default bucket large enough so it's not a concern

You can use this and it works with envoyfilter
kind: EnvoyFilter
metadata:
  annotations:
  name: ext-authz
  namespace: ats
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_INBOUND
      listener:
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.filters.http.local_ratelimit
        typed_config:
          "@type": type.googleapis.com/udpa.type.v1.TypedStruct
          type_url: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
          value:
            stat_prefix: http_local_rate_limiter

  - applyTo: HTTP_ROUTE
    match:
      context: SIDECAR_INBOUND
      routeConfiguration:
        vhost:
          name: ""
          route:
            action: ANY
    patch:
      operation: MERGE
      value:
        route:
          rate_limits:
            - actions: # any actions in here
              - request_headers:
                  header_name: ":path"
                  descriptor_key: "path"
        typed_per_filter_config:
          envoy.filters.http.local_ratelimit:
            "@type": type.googleapis.com/udpa.type.v1.TypedStruct
            type_url: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
            value:
              stat_prefix: http_local_rate_limiter
              token_bucket:
                max_tokens: 400
                tokens_per_fill: 400
                fill_interval: 60s
              filter_enabled:
                runtime_key: local_rate_limit_enabled
                default_value:
                  numerator: 100
                  denominator: HUNDRED
              filter_enforced:
                runtime_key: local_rate_limit_enforced
                default_value:
                  numerator: 100
                  denominator: HUNDRED
              response_headers_to_add:
                - append: false
                  header:
                    key: x-local-rate-limit
                    value: 'true'
              descriptors:
                - entries:
                  - key: path
                    value: /hello1
                  token_bucket:
                    max_tokens: 2
                    tokens_per_fill: 2
                    fill_interval: 60s


Improve Travis integration: linting

Should be green for now, but only vint-errors is required to pass:
https://travis-ci.org/blueyed/neomake/builds/133748148

Should be ready.
Current build is: https://travis-ci.org/blueyed/neomake/builds/133773874
I plan to merge this soon and will then re-enable Travis for PRs.

please add an build status icon into readme.md

Done.  Also enabled Travis again - it should show up here.
I will merge it when it's green again/still.