These all sound like very valid reasons. I personally decided against using Godot solely because of the way it handles data streaming. It seems it has no built in way to manage terrain for an open-world game and I doubt I'd be capable of adding in such functionality directly into the engine myself without spending a decade doing so. So, for me, I feel to complete my vision, I'll need to use Unreal. Though, Unreal is so bloated, I'm not confident any existing engine would be ideal without serious work arounds and edits to how it functions anyway.
The people developing the Terrain3D plugin for Godot are doing some incredible work that's just getting better every day, so I highly recommend you check it out if you're ever interested! In the meantime, I'm sure Unreal will serve you well as they've been doing some awesome stuff too with Nanite & Lumen. For me Unreal ends up with the same licensing/source visibility issues as Unity but I do hope an Unreal FOSS competitor can make its way to the market some day. And I do think a lot of lessons can be learned from Unreal's workflow/high end graphics features too, would be great to see some of that reflected in Godot. Hope you find what works best for you, thanks for watching!
Great video! It defintely didn't come accorss as bashing godot, its clear that you would like to use it but certin limitations hold you back. In general I agree with all of these points, with the exception of node management and "Resource buildup". With the nodes, its just moving the behavour clutter from one place to another. With the buildup of things extending resource, isn't it good to define data structures somewhere? Games have a ton of project files, and a few more to describe the structure of a resource isnt really a big deal imo. You mentioned having hundreds of them, but if you need that many data structures isnt that still a very small part of the game?
@@tryoxiss Thanks so much for watching! Yes, both of those are a bit of a nitpick and some of my pain points stem from simply working with the hierarchy/code in a way I’m not used to. However I tend to prefer cluttering up a behavior stack over cluttering up the hierarchy because it provides a cleaner separation between topics for me. Without better visualization UI, nodes that hold scripts seem to blend in with nodes that simply represent positions or act as parent objects, and that becomes more time consuming to click through rather than knowing everything relevant to an entity is on the parent object. Also from the code, you end up traversing the tree a lot more when getting references to scripts you depend on. Most of it comes down to preference yeah but I guess it has to do a lot more with UX and how easy it is to parse scenes. And as I mentioned in the video, node count affects performance so any time I need an extra node for a script I feel like it’s a wasted opportunity to save some performance, especially if it’s on an NPC that’s duplicated dozens of times in a scene for example. For the resource stuff, I do tend to use a lot of subclasses when I program because it keeps relevant data structures contained to the class it’s meant to be used in, which helps with organization. If I was to use resources for one of my games Shinogi Chess Club (which features a lot of state data for the board game sections) it would absolutely triple the number of script files. It’s true that I could create data structures outside of resources but then they’re not editable in the inspector, so I can’t play with values at runtime or set up easily edited defaults. I’ve been having discussions with the people creating struct support for Godot and I’m confident it will lead to being able to edit user structs in the inspector, which will solve part of this issue as I won’t need to use resources. Again it’s not a huge deal and I can work with it for now but I hope that explains a bit why it’s a big departure from what I’m used to :)
I tried Godot for a year now, mostly for 3D. I ended up saving every animation on import and created an animation library that I used on the animation players. It worked pretty well, but it was far from being intuitive or flexible. 3D performance is another thing I'm not really satisfied with. The asset workflow can be cumbersome and moving files often lead to a crash. And the UI can be annoying to work with, for example the inspector when there are plenty of child foldouts. Despite all that I had fun using it, I like GD script and some other things but I won't use Godot for larger or 3D projects right now.
@@TrizZzle I feel the same, there’s a lot more steps involved for working with 3D projects specifically and I worry about encountering crashes/corruptions that cause permanent issues. As I demoed in the video, just changing import settings on a blender file can brick existing inherited scenes until you create a new one. Git will help correct meta file issues but since I use Photoshop files that exceed 100MB I can’t push everything to a repository and I use automated backups instead, not ideal for correcting corruption. I’m confident all this stuff can be smoothed over, it’s just tricky because there’s a lot of specific little quirks that aren’t always easy to track down. Thanks for your thoughts :)
This is an interesting perspective. I've heard about the controversial decision that Unity had made, but to hear it from your perspective and comparison to Godot is interesting. I think it will be healthy for the industry to have both Unity and Godot to exist in tandem to encourage a healthy competition. That will drive better engines for developers to use.
Absolutely, everyone should feel free to use the tools that work best for them and it's thanks to these options that we can improve every engine with new ideas. Even though Godot is open source, I think it should "compete" in that space and drive other open source engines to do the same; when it's closer in feature parity to Unity it will be much more enticing to even AA studios to use the software that has a more open license, so I'm looking forward to contributing more and creating packages that help Godot reach that point :D
17:50 I don't think this problem can be solved, given that the node and the script are the same thing. Nodes in Unity and in Godot mean different things in meaning.
Yes, that's true and perhaps that is why I'd prefer it to work differently since for me scenes are easier to parse when the data points/code are more clearly separated from the visual elements like UI for example. This might be something that can be addressed with a UX update, like imagine if we could create "behavior nodes" which, while technically are child Nodes, don't appear in the hierarchy and just stack up in a list on the parent with all fields exposed. This is something that could provide faster access to scripts with better ease of use since you are managing less child nodes, keeping the hierarchy (and code itself!) cleaner. I think the closest thing you can create right now would be a "component bus" that marks some parent node as a component holder which auto loads scripts that derive from a custom "component" class. From the component class you can more easily access the parent node/other components on that node through helper functions. I'm going to be looking into creating a plugin like this in the future which should help with the management of data/references, and hope that we get some UI labeling/visibility features for the hierarchy to help with ease of use. But in the end this point is mostly a nitpick and one that I can work around with my own solutions :)
Redot might be something to be interested in, it is trying to make sure that Godot [they are rebranding it to Redot because they are forking it from Godot] is more functionally fluid and stable compared to Godot and its stated slow development cycle. as well as a recent controversy that happened being the last straw. Hope you have a great day & Safe Travels!
Thanks for watching, though I want to make clear that I do not support or condone Redot in any capacity. I elaborated further on this in the video description, but I will explain this here as well. Of course anyone is free to fork and modify Godot for their own purposes, but Redot being created in response to the "drama" leaves a sour taste in my mouth, regardless of what their stated goals are. And what kind of message is that supposed to send anyways? That they disagree with the Godot foundation promoting LGBTQ games/poking fun at the statement "all game engines are woke"? Does that mean Redot creators DO believe that all game engines are "woke", or do they believe something even more sinister, that LGBTQ creators should not be highlighted and celebrated? Even if you take their goals out of the equation, in what way is Redot "more functionally fluid and stable" than Godot? So far all they have done is rebrand. What is even the separation between that and regular Godot if they're pulling in commits from the main repo anyways? Why would anyone use Redot if the two projects are nearly identical currently, just so that they don't have to give Godot credit/associate with them? If their hope is to advance features beyond Godot somewhere in the future, I very much believe people will soon find that they can never hope to keep up with the stability offered by Godot simply because it has more eyes on it and has legitimate investment and support put into it. In the best case, Redot is simply an experimental version of the engine that will have less support & less bugfixes, and in the worst case Redot is a statement against inclusivity. In either case, I am not interested in something like that. If there's going to be a fork that plays around with cutting edge features, it should present itself in such a way that doesn't undermine the original project. Despite my qualms with feature priority, Godot's mission and goals are sound, and I have no desire to associate with any project that believes otherwise.
@@robproductionsgames alright those are good points. though with the statement of it *being* streamlined and fixing bugs [tons of not taken care of PR's in Godot], they do state that as their main reasoning for forking Godot and the controversy as the final straw that broke the camel's back. they also acknowledge that currently there is no difference between Godot and them [tech-wise], but that they might soon diverge if their interests don't align with Godot's in a technical fashion. they state that as their purpose, not as their current state to be better with pull-requests and make sure the game engine runs well. Second, the statement that Redot is against inclusivity is actually part of the issue. they aren't actively saying that or doing anything to that notion, heck some people of said LGBTQ community were attacked for the "focus on game engine development" mindset from Godot and support Redot themselves. Redot wants to focus on game engine development solely and not identity politics which do divide people [and thus shed developers and supporters alike]. the issue is that statement is being thrown at Redot for them forking the project with no research into the matter, by people from Godot last I checked. so... I don't see how Redot forking for better game development focus and designing roadmaps would be against inclusivity either, but they were harassed for it anyways. in fact I would think that Godot should be considered less inclusive with their "purge of the undesirables" comments. I would think that line would leave a sour taste in your mouth, it sure did in mine. third, Godot did ban their paying contributors via said controversy. so I am sure that is a major issue if even the paying contributors got banned, not just from twitter; but also Github for statements that were totally justified which were "focus on the game engine development" in nature, since that is the stated goal of the project. this is why Godot has problems. it is against inclusivity by those actions more so than Redot. especially with how they treated the situation of the unreasonable bans/blocks via their response [putting sole blame on "certain" users; also I note there were actual people doing bad stuff... but the response was definitely over-blown by the community manager]. I would also state some of their comments [calling them slurs and other such behaviors degrading their user-base as filth] about said people voicing legitimate worries and concerns about things such as bitmap support or other such things getting blocked causes issues as well. which will cause instability from developers being unable to aid the project and thus it will lose its momentum as well as the source code quality. it would also potentially cause some worry from paying contributors if even they who support Godot financially can't have a say in how it is made, thus providing an unstable base of funds. especially if they pay and the get blocked, even as a platinum supporter. it is ultimately your decision whether to further talk about or utilize Redot or not. I just wanted to say my points on the matter and clarify that Redot merely forked the Engine code, and then got harassed for it; because they wanted to make a safe and inclusive space for all game developers, not just one party of political thought. thank you for your video and comments. Hope you have a great day & Safe Travels!
@@TheSensationalMr.Science Thank you for sharing your thoughts in a respectful manner. It's good that they have not stated any opposition towards the inclusivity that Godot strives to achieve, but if Redot is born of matters outside of the technical i.e. the "controversy", then they're not truly focused on technology only, right? Regardless of what they claim, people will flock to it *because of* the controversy, and while I don't want to make sweeping claims about Redot's userbase, this puts them in a position of attracting people who "disagree" with the Godot Foundation's tweet; in other words they attract people who truly believe that "game engines are woke" or that LGBTQ games should not be showcased. To put it in another perspective, Godot Foundation made a tweet poking fun at "all game engines are woke"; they did not make any official response or state any stance on the matter, they were simply following a trend which had unanimous support in the days leading up to the tweet, a trend that was perpetuated by many others in the gamedev sphere. Where is the "politics" in that? Regardless of your political beliefs, why is it so controversial to say that that claim about game engines is absurd? So if Redot comes in and says "let's not focus on politics", what is the takeaway? Which "politics" are they talking about and take issue with? Based on their actions, not their words, it appears as though they are opposed to publicly supporting the LGBTQ community the way Godot did. It is a shame that some people were blocked in the cross fire, however can you really blame the community manager considering the absolute cesspool that Twitter has become? It's impossibly difficult to differentiate between genuine comments and people trying to purposefully troll and harass. The CM is still to this day *personally attacked* on RUclips and Twitter, so I honestly don't think it is an issue to play it safe and just cut off anyone who could potentially feed into that. We also have confirmation, at least as of the making of this video, that only a handful of Github users were banned and it was because they were making troll issues, which is against the code of conduct. Where exactly did Godot foundation members call people slurs? I have not heard anything of the sort from people who are officially involved with the project. Giving them platinum support doesn't give you the right to say whatever you want in the Godot community. It doesn't matter who pays what or what your contribution is, everyone must follow the code of conduct. You can not create a "safe and inclusive" space for literally everyone, because it invites harassers to say or do anything they want and bully people. So if this is Redot's goal, then here is a question: what happens when a member of the Redot community starts saying terrible things about the LGBTQ community? Will that person get banned, or will they be applauded for exercising their "right to free speech"? These are the questions you have to ask when they challenge Godot's support of the LGBTQ community. I don't want to judge you or anyone who uses Redot, but it is for these reasons that I can't support it in any capacity and I want to pose these questions for people who consider it because I fear for what it stands for. Even if the creators have the best of intentions, I worry that it forming in the midst of the Twitter reactions will cause a certain audience to latch on to it and twist into something awful. Perhaps they can prove me wrong and keep those people out of it, but I'm not holding my breath.
@@robproductionsgames Not only do you echo nearly every thought I had on the situation, but you state your position with profound clarity, logic and tact. I respect you wholeheartedly for your comments here. Thank you. Genuinely.
These all sound like very valid reasons. I personally decided against using Godot solely because of the way it handles data streaming. It seems it has no built in way to manage terrain for an open-world game and I doubt I'd be capable of adding in such functionality directly into the engine myself without spending a decade doing so. So, for me, I feel to complete my vision, I'll need to use Unreal. Though, Unreal is so bloated, I'm not confident any existing engine would be ideal without serious work arounds and edits to how it functions anyway.
The people developing the Terrain3D plugin for Godot are doing some incredible work that's just getting better every day, so I highly recommend you check it out if you're ever interested! In the meantime, I'm sure Unreal will serve you well as they've been doing some awesome stuff too with Nanite & Lumen.
For me Unreal ends up with the same licensing/source visibility issues as Unity but I do hope an Unreal FOSS competitor can make its way to the market some day. And I do think a lot of lessons can be learned from Unreal's workflow/high end graphics features too, would be great to see some of that reflected in Godot. Hope you find what works best for you, thanks for watching!
Such a needed video! Learned a lot from hearing your thoughts :)
Great video! It defintely didn't come accorss as bashing godot, its clear that you would like to use it but certin limitations hold you back. In general I agree with all of these points, with the exception of node management and "Resource buildup". With the nodes, its just moving the behavour clutter from one place to another. With the buildup of things extending resource, isn't it good to define data structures somewhere? Games have a ton of project files, and a few more to describe the structure of a resource isnt really a big deal imo. You mentioned having hundreds of them, but if you need that many data structures isnt that still a very small part of the game?
@@tryoxiss Thanks so much for watching! Yes, both of those are a bit of a nitpick and some of my pain points stem from simply working with the hierarchy/code in a way I’m not used to. However I tend to prefer cluttering up a behavior stack over cluttering up the hierarchy because it provides a cleaner separation between topics for me. Without better visualization UI, nodes that hold scripts seem to blend in with nodes that simply represent positions or act as parent objects, and that becomes more time consuming to click through rather than knowing everything relevant to an entity is on the parent object. Also from the code, you end up traversing the tree a lot more when getting references to scripts you depend on. Most of it comes down to preference yeah but I guess it has to do a lot more with UX and how easy it is to parse scenes. And as I mentioned in the video, node count affects performance so any time I need an extra node for a script I feel like it’s a wasted opportunity to save some performance, especially if it’s on an NPC that’s duplicated dozens of times in a scene for example.
For the resource stuff, I do tend to use a lot of subclasses when I program because it keeps relevant data structures contained to the class it’s meant to be used in, which helps with organization. If I was to use resources for one of my games Shinogi Chess Club (which features a lot of state data for the board game sections) it would absolutely triple the number of script files. It’s true that I could create data structures outside of resources but then they’re not editable in the inspector, so I can’t play with values at runtime or set up easily edited defaults. I’ve been having discussions with the people creating struct support for Godot and I’m confident it will lead to being able to edit user structs in the inspector, which will solve part of this issue as I won’t need to use resources. Again it’s not a huge deal and I can work with it for now but I hope that explains a bit why it’s a big departure from what I’m used to :)
I tried Godot for a year now, mostly for 3D. I ended up saving every animation on import and created an animation library that I used on the animation players. It worked pretty well, but it was far from being intuitive or flexible. 3D performance is another thing I'm not really satisfied with. The asset workflow can be cumbersome and moving files often lead to a crash. And the UI can be annoying to work with, for example the inspector when there are plenty of child foldouts. Despite all that I had fun using it, I like GD script and some other things but I won't use Godot for larger or 3D projects right now.
@@TrizZzle I feel the same, there’s a lot more steps involved for working with 3D projects specifically and I worry about encountering crashes/corruptions that cause permanent issues. As I demoed in the video, just changing import settings on a blender file can brick existing inherited scenes until you create a new one. Git will help correct meta file issues but since I use Photoshop files that exceed 100MB I can’t push everything to a repository and I use automated backups instead, not ideal for correcting corruption.
I’m confident all this stuff can be smoothed over, it’s just tricky because there’s a lot of specific little quirks that aren’t always easy to track down. Thanks for your thoughts :)
This is an interesting perspective. I've heard about the controversial decision that Unity had made, but to hear it from your perspective and comparison to Godot is interesting. I think it will be healthy for the industry to have both Unity and Godot to exist in tandem to encourage a healthy competition. That will drive better engines for developers to use.
Absolutely, everyone should feel free to use the tools that work best for them and it's thanks to these options that we can improve every engine with new ideas. Even though Godot is open source, I think it should "compete" in that space and drive other open source engines to do the same; when it's closer in feature parity to Unity it will be much more enticing to even AA studios to use the software that has a more open license, so I'm looking forward to contributing more and creating packages that help Godot reach that point :D
One of us! One of us!
17:50 I don't think this problem can be solved, given that the node and the script are the same thing. Nodes in Unity and in Godot mean different things in meaning.
In fact, a node with several scripts is the same as a scene with several child elements
Yes, that's true and perhaps that is why I'd prefer it to work differently since for me scenes are easier to parse when the data points/code are more clearly separated from the visual elements like UI for example. This might be something that can be addressed with a UX update, like imagine if we could create "behavior nodes" which, while technically are child Nodes, don't appear in the hierarchy and just stack up in a list on the parent with all fields exposed. This is something that could provide faster access to scripts with better ease of use since you are managing less child nodes, keeping the hierarchy (and code itself!) cleaner.
I think the closest thing you can create right now would be a "component bus" that marks some parent node as a component holder which auto loads scripts that derive from a custom "component" class. From the component class you can more easily access the parent node/other components on that node through helper functions. I'm going to be looking into creating a plugin like this in the future which should help with the management of data/references, and hope that we get some UI labeling/visibility features for the hierarchy to help with ease of use. But in the end this point is mostly a nitpick and one that I can work around with my own solutions :)
Redot might be something to be interested in, it is trying to make sure that Godot [they are rebranding it to Redot because they are forking it from Godot] is more functionally fluid and stable compared to Godot and its stated slow development cycle. as well as a recent controversy that happened being the last straw.
Hope you have a great day & Safe Travels!
Thanks for watching, though I want to make clear that I do not support or condone Redot in any capacity. I elaborated further on this in the video description, but I will explain this here as well. Of course anyone is free to fork and modify Godot for their own purposes, but Redot being created in response to the "drama" leaves a sour taste in my mouth, regardless of what their stated goals are. And what kind of message is that supposed to send anyways? That they disagree with the Godot foundation promoting LGBTQ games/poking fun at the statement "all game engines are woke"? Does that mean Redot creators DO believe that all game engines are "woke", or do they believe something even more sinister, that LGBTQ creators should not be highlighted and celebrated?
Even if you take their goals out of the equation, in what way is Redot "more functionally fluid and stable" than Godot? So far all they have done is rebrand. What is even the separation between that and regular Godot if they're pulling in commits from the main repo anyways? Why would anyone use Redot if the two projects are nearly identical currently, just so that they don't have to give Godot credit/associate with them? If their hope is to advance features beyond Godot somewhere in the future, I very much believe people will soon find that they can never hope to keep up with the stability offered by Godot simply because it has more eyes on it and has legitimate investment and support put into it.
In the best case, Redot is simply an experimental version of the engine that will have less support & less bugfixes, and in the worst case Redot is a statement against inclusivity. In either case, I am not interested in something like that. If there's going to be a fork that plays around with cutting edge features, it should present itself in such a way that doesn't undermine the original project. Despite my qualms with feature priority, Godot's mission and goals are sound, and I have no desire to associate with any project that believes otherwise.
@@robproductionsgames alright those are good points. though with the statement of it *being* streamlined and fixing bugs [tons of not taken care of PR's in Godot], they do state that as their main reasoning for forking Godot and the controversy as the final straw that broke the camel's back. they also acknowledge that currently there is no difference between Godot and them [tech-wise], but that they might soon diverge if their interests don't align with Godot's in a technical fashion. they state that as their purpose, not as their current state to be better with pull-requests and make sure the game engine runs well.
Second, the statement that Redot is against inclusivity is actually part of the issue. they aren't actively saying that or doing anything to that notion, heck some people of said LGBTQ community were attacked for the "focus on game engine development" mindset from Godot and support Redot themselves. Redot wants to focus on game engine development solely and not identity politics which do divide people [and thus shed developers and supporters alike]. the issue is that statement is being thrown at Redot for them forking the project with no research into the matter, by people from Godot last I checked. so... I don't see how Redot forking for better game development focus and designing roadmaps would be against inclusivity either, but they were harassed for it anyways.
in fact I would think that Godot should be considered less inclusive with their "purge of the undesirables" comments. I would think that line would leave a sour taste in your mouth, it sure did in mine.
third, Godot did ban their paying contributors via said controversy. so I am sure that is a major issue if even the paying contributors got banned, not just from twitter; but also Github for statements that were totally justified which were "focus on the game engine development" in nature, since that is the stated goal of the project. this is why Godot has problems. it is against inclusivity by those actions more so than Redot. especially with how they treated the situation of the unreasonable bans/blocks via their response [putting sole blame on "certain" users; also I note there were actual people doing bad stuff... but the response was definitely over-blown by the community manager].
I would also state some of their comments [calling them slurs and other such behaviors degrading their user-base as filth] about said people voicing legitimate worries and concerns about things such as bitmap support or other such things getting blocked causes issues as well. which will cause instability from developers being unable to aid the project and thus it will lose its momentum as well as the source code quality. it would also potentially cause some worry from paying contributors if even they who support Godot financially can't have a say in how it is made, thus providing an unstable base of funds. especially if they pay and the get blocked, even as a platinum supporter.
it is ultimately your decision whether to further talk about or utilize Redot or not. I just wanted to say my points on the matter and clarify that Redot merely forked the Engine code, and then got harassed for it; because they wanted to make a safe and inclusive space for all game developers, not just one party of political thought.
thank you for your video and comments.
Hope you have a great day & Safe Travels!
@@TheSensationalMr.Science Thank you for sharing your thoughts in a respectful manner. It's good that they have not stated any opposition towards the inclusivity that Godot strives to achieve, but if Redot is born of matters outside of the technical i.e. the "controversy", then they're not truly focused on technology only, right? Regardless of what they claim, people will flock to it *because of* the controversy, and while I don't want to make sweeping claims about Redot's userbase, this puts them in a position of attracting people who "disagree" with the Godot Foundation's tweet; in other words they attract people who truly believe that "game engines are woke" or that LGBTQ games should not be showcased.
To put it in another perspective, Godot Foundation made a tweet poking fun at "all game engines are woke"; they did not make any official response or state any stance on the matter, they were simply following a trend which had unanimous support in the days leading up to the tweet, a trend that was perpetuated by many others in the gamedev sphere. Where is the "politics" in that? Regardless of your political beliefs, why is it so controversial to say that that claim about game engines is absurd? So if Redot comes in and says "let's not focus on politics", what is the takeaway? Which "politics" are they talking about and take issue with? Based on their actions, not their words, it appears as though they are opposed to publicly supporting the LGBTQ community the way Godot did.
It is a shame that some people were blocked in the cross fire, however can you really blame the community manager considering the absolute cesspool that Twitter has become? It's impossibly difficult to differentiate between genuine comments and people trying to purposefully troll and harass. The CM is still to this day *personally attacked* on RUclips and Twitter, so I honestly don't think it is an issue to play it safe and just cut off anyone who could potentially feed into that. We also have confirmation, at least as of the making of this video, that only a handful of Github users were banned and it was because they were making troll issues, which is against the code of conduct. Where exactly did Godot foundation members call people slurs? I have not heard anything of the sort from people who are officially involved with the project.
Giving them platinum support doesn't give you the right to say whatever you want in the Godot community. It doesn't matter who pays what or what your contribution is, everyone must follow the code of conduct. You can not create a "safe and inclusive" space for literally everyone, because it invites harassers to say or do anything they want and bully people. So if this is Redot's goal, then here is a question: what happens when a member of the Redot community starts saying terrible things about the LGBTQ community? Will that person get banned, or will they be applauded for exercising their "right to free speech"? These are the questions you have to ask when they challenge Godot's support of the LGBTQ community.
I don't want to judge you or anyone who uses Redot, but it is for these reasons that I can't support it in any capacity and I want to pose these questions for people who consider it because I fear for what it stands for. Even if the creators have the best of intentions, I worry that it forming in the midst of the Twitter reactions will cause a certain audience to latch on to it and twist into something awful. Perhaps they can prove me wrong and keep those people out of it, but I'm not holding my breath.
@@robproductionsgames
Not only do you echo nearly every thought I had on the situation, but you state your position with profound clarity, logic and tact. I respect you wholeheartedly for your comments here. Thank you. Genuinely.