r/godot 2d ago

help me Why is “Make Unique” the most painful feature in Godot?

So, I’ve been working with Godot for a while now, and honestly, one of the most “well-intended” features has also turned out to be the most painfully annoying: Make Unique.

Every time you duplicate something, Godot automatically shares its resources with the original. Sure, in theory that sounds amazing — memory efficient, clean, no duplicates. But in practice? It’s a nightmare.

Example: I’m making like 10 different plants. They’re all pretty similar, just with different meshes and gradients. I duplicate one, swap the mesh, start adjusting the gradient colors… and then realize I forgot to hit Make Unique. Boom. All my other plants just got overwritten, and the work I did is gone.

This happens to me all the time because I simply forget to press it. And I get why this feature exists — resource sharing is smart. But from a development perspective, it’s just so painful. I really wish there was a setting to turn this off, so that every new scene/node automatically gets its own unique materials/resources unless I explicitly tell it to share.

Does anyone else feel this way? Or am I just missing some hidden Godot checkbox that makes this less frustrating?

300 Upvotes

85 comments sorted by

169

u/NeverQuiteEnough 2d ago

Save your resources!

Leaving your resources floating in the editor is ok for prototyping, but beyond that you really want to be saving them somewhere.

31

u/_michaeljared 2d ago

Yeah this is definitely true. Sometimes it gets a little bit redundant: for instance, you have a ShaderMaterial that has encoded values for several shader uniforms, and that ShaderMaterial is always applied to a particular mesh (but not shared across meshes).

You might not want to save a resource for the ShaderMaterial in that case because it ends up being one more resource to manage in your filesystem. But as soon as two meshes what that ShaderMaterial, you'll need to save it so you can re-use it.

That's generally my approach to reduce clutter.

1

u/LostSleepGames 10h ago

Yep. One shader may be used by many materials, just with unique parameters. I save both to files but mostly cuz I’ve been burned by Blender auto-import randomly nuking my override materials so I always keep a backup of custom materials now. Lesson learned.

EDIT: and by “randomly” I mean I “randomly” decide to rename an object in my .blend file so Godot loses the reference to the original overridden mesh :P

27

u/SomeWittyRemark 1d ago

I broadly agree with this but also I am not saving every curve I use in a particle system when they will never be used again.

5

u/NeverQuiteEnough 1d ago

That's very true

1

u/Less-Set-130 Godot Junior 6h ago

Once I had an issue with an instant mesh.I used it to make a line3d. It really didn't make sense to save it as a resource. Took a while until I figured out to make it unique so each instance actually went where it should go.

256

u/HeyCouldBeFun 2d ago

It’s how it should work - resources are objects and objects are passed by reference. It’s the UI that doesn’t make this explicitly clear. IMO it’d be better if resources were always saved separately from scenes.

39

u/Worldsday 1d ago

In Blender, this is addressed simply by displaying a little number next to the datablock (i.e. resource), indicating how many other objects use it.

8

u/Ok-Jellyfish-8474 1d ago

Yes, but in blender you have to try to duplicate with linked data
The default is usually to automatically "make unique"

I agree with Blender and OP in that people who don't understand the underlying reference system should be punished with poor performance, not losing work

I also don't think the subresources of one resource should be importable by another resource. If you want to share a resources, save it in its own file

1

u/Worldsday 1d ago

I understand. Though I wouldn't mind having to manually "make unique" if there were a little number that reminded me to do so

47

u/voli12 2d ago

Yes, but sometimes you just need a curve or quick material, and having it separate would bloat the project significantly.

18

u/KDOXG Godot Regular 1d ago

This means then that the solution is more about being able to define which kind of resource should be local only or be shared between scenes. This clearly seems like something that should be handled by the UI during defining the kind of resources the scene will need, but currently we group so many different kinds of resources with so many different purposes — in the end, working on the scene design already feels way too bloated, with so many manual work! That's why I also prefer saving the resources separately from scenes. Make Unique should be a feature to allow exceptions and special cases, not part of the scene design.

Seriously, it's due time that the Godot Editor should receive a really huge update for it's UI — and by that I'm also including how the .tscn files works. All updates on UI for Godot 4 were extremely mild, even the current version is still very similar to what we had in Godot 3.

3

u/Polar-ish 1d ago

i feel ideally it would be a distinction when copying, ctrl+shift+c copies every piece of a node as if they are unique, ctrl+c simply copies a reference to the node

5

u/trickster721 1d ago

Do you really want Godot to force you to save every collision shape as a separate file? Unity uses tons of separate files for every tiny data asset, and I always found it a big hassle. Godot's (totally optional) embedded resource system was a breath of fresh air.

If you want to try the Unity experience, just right-click a folder every time you want to create a new resource, select Create New and Resource, then select your resource type from the giant list, then edit your new resource on the inspector and save it as a file, then go back to your node, and drag your resource into the inspector slot. Sound like fun?

1

u/huntsweez 1d ago

This process being overly converluted, easy to fuck up and simply tedious and not fun is exactly the point of OPs post.

1

u/trickster721 23h ago

Sure, but what I'm saying is that if you think about how it should work instead of how it shouldn't, there's no obvious way to solve the problem. It's like saying "Remembering to lock my door is annoying, so I want a door that locks itself when it should, and unlocks when it should." Okay, but... what does that mean? The door can't read your mind. What rules should the engine follow to duplicate resources only when you want it to?

1

u/huntsweez 11h ago

By default, file resources should not be made unique when duplicating an object, embedded resources should be made unique when duplicating the object.

Additionally there should be a visual indicator in the inspector to see on a glance which resources are shared and which are unique.

If this does not find consens, at the very least have two duplication methods in the contect menu: Duplicate (with shared Resources) Duplicate (with unique Resources)

-31

u/TheDuriel Godot Senior 2d ago

You can just... do that. Fyi.

17

u/HeyCouldBeFun 2d ago

I mean by default.

0

u/WittyConsideration57 1d ago

So clone/extend a base resource

-5

u/Nkzar 2d ago

It does. By default it saves them embedded in the PackedScene resource. You can even directly reference that as embedded resources of the scene resource from other scenes (you really shouldn’t though).

-24

u/TheDuriel Godot Senior 2d ago

What default?

You choose where to create and save the resource. Godot doesn't make that decision for you.

2

u/BluMqqse_ 1d ago

What default?

The default when you choose "New X Resource". It creates a resource local to the scene. You have to actively go out of your way to right click "Save As" to give a unique save location.

Do you purposefully act dense?

1

u/TheDuriel Godot Senior 1d ago

It only does that if you do it inside a property. Go to the file dock.

This is exactly what I mean. You chose to make an embedded resource. You pressed the button that explicitly, does only that. The other button is right there for you to press instead.

72

u/nobix 2d ago

I think this is just an opportunity to improve the UI here. It should be clearer that it is shared, e.g. give it a frame to show how many references there are.

But I also I think making them deep copy should be a default option. You can always save them as resources to make it more explicitly shared.

16

u/ericsnekbytes 2d ago

Exactly, better communication and better tooling to make managing this stuff better would be fantastic (especially around embedded resources which I mentioned elsewhere).

I'm less convinced about changing the default (maybe this could be an option). But if Godot communicated its philosophy inside the editor better, we would likely have less problems and confusion.

There are lot of docs, but it's a mountain of material, especially when you're a first time game dev and you're absolutely being tsunami'd with new information. We should make digesting and consuming this stuff as easy as possible for new people, and not pretend that it isn't difficult.

2

u/huntsweez 1d ago

For embeded resources duplication should be unique by default.

Noone expects attached scripts or textures to be unique when duplicating an object. This is because everyone knows these are separate files on harddrive. 

When you duplicate an object with an embeded resource (like the shape for CollisionShape), most people would expect this resource to be as unique as the duplicated object.

The problem is Godot does not make this destinction. For Godot every Resource is always shared, unless the User explicitly tells Godot not to share it.

2

u/NickFegley 1d ago

What's the UI solution here? Color coding unique/shared resources? A little pop-up? A label that tells you how many scenes are sharing a resource?

1

u/nobix 1d ago

Right now there is a text field that says the name of the resource in the property.

If it's a saved resource then it shows the filename of that resource, which is a clue at least that editing this will edit one shared resource.

If it's a unique/shared inline resource it just says the resource name and it says the same thing under both circumstances. Just adding a 'unique' and 'shared' text string would help here.

But also I think I would prefer them to always be unique, and then combine them during export if they are the same.

25

u/Seraphaestus Godot Regular 1d ago edited 1d ago

I promise if it was the other way round by default you would forget to tell it to share materials etc. way more often than you make errors now. You would end up with a bloated project with a dozen invisible duplicates of static materials, for no reason. Forgetting to make unique, on the other hand, might be frustrating, but it is noisy and you can't miss it when it happens. You want catastrophic errors, not silent errors.

I mean, truly consider what you're asking for. You want it that every time you copy a meshinstance, it creates a new copy of the model file, and a new copy of the texture file, on your file system? Sounds like a nightmare

1

u/Accurate-House-5510 1d ago

I honestly have no idea how duplicating a resource would ever become an issue for most developers. I mean most resources aren't very memory intensive, right? Unless you're duplicating very complex meshes, but then again isn't the resource itself holding only a reference to the actual mesh? Then we are simply duplicating a few bytes of data. How can that ever be an issue? Unless you're duplicating millions of nodes in your editor, but then I'm fairly certain something else would break first.

34

u/Nkzar 2d ago

No I like it just the way it is. It stems from a misunderstanding of the Godot editor: it is a Resource editor. I want to re-use my existing resources when duplicating a node. If I want different data I create a new instance of that resource or (very rarely) use Make Unique.

Make Unique should be a rare thing in your workflow.

18

u/DJ_Link Godot Regular 2d ago

Def agree with that, while it can be annoying, unique should be the exception and not the rule.

Reminds me of something I saw a few years ago, always const a var when declaring and then check if you really need to change it and why. Seems weird at first but it’s a valid point.

1

u/huntsweez 1d ago

Imho only externally saved resources should be shared by default and embeded resources should be unique like the object the are embedded with.

6

u/SnooPets752 1d ago

That's a feature. And a good one.  I had a scene that had a world block that I had to rework entirely. If the default was creating a unique instead of a link, it works have meant re adding everything manually. This happens constantly when you work on a game and things change slightly. 

With your case, at least now you won't make the same mistake. 

7

u/Planet1Rush 1d ago

What I’d really like to learn is: how could I add an option (a checkbox in the project settings) to control this behavior? For example:

  • [ ] Share resources (default)
  • [x] Duplicate resources as unique

Basically, I want duplicated nodes to automatically create unique resources instead of shared references, without having to press Make Unique every single time.

Does anyone know where in the Godot source code I’d need to look, or if there’s already a plugin or mod that does this? This has been bugging me for 1–2 years, and I’d love to finally fix it for my workflow.

2

u/[deleted] 1d ago

You'd have to check the Editor folder in the Godot source code (it's the SceneTreeDock if I'm not mistaken?) 

Though I would advise against it, as much as I have resented resources, I guess an opt in solution is best than opt out? As a compromise (something I did initially before working on my PRs) you could add a check in the source code if Local to Scene is checked, then duplicate it as well. This way you only need to press it once as soon as you create a resource and it's good to go.

Nevertheless if this solves the issue for you, go ahead! 

14

u/Head-View8867 2d ago

Respectfully, could this just be fixed by approach? Instead of editing from the inspector, shouldn't you make a new resource or scene instance and inherit from the base "plant" if needed?

I am very amateur so please correct me if I'm wrong

2

u/EeeeJay 1d ago

You are on it, as another comment further up said. 

This is called Inheritance and/or Polymorphism in programming, and is core to the OOP nature of Godot.

6

u/HyperGameDev 1d ago

I do think deep copy as the default duplicate operation would be bad.

I also think more clarity that something is or isn't unique would be good.

Maybe a link (🔗) icon in the inspector that, on click, shows all the objects sharing that resource. Or on hover, a tooltip explains what the link means.

44

u/TheDuriel Godot Senior 2d ago

The scenario you describe can't even happen with scenes. Since instances of scenes, do not, share changes made to them. Even with editable children. This scenario can only happen with resources.

In which case, why are you copying the resource instead of just making a new one?


As for scenes. This is what @export properties are for to manage.

2

u/ericsnekbytes 2d ago

Because copy paste is usually the easiest and most common sense way to make copies or variations of similar subtrees.

I want to give you the benefit of the doubt here, but it seems like you're deliberately being obtuse about this, surely you know how common copy/paste is for subtrees where you don't want to reconstruct everything from scratch.

Resource sharing is great sometimes, but absolutely the editor could do a better job of allowing game devs to control these things at a granular level in a much more convenient way (tools and functionality in the editor around embedded resources in particular could be much better).

15

u/ericsnekbytes 1d ago

Just take a moment and reflect on why we keep seeing these kinds of posts all the time...it's not indicative of a system that is very clear and intuitive for users. Listen to people when they say something is confusing! It's a path toward a better Godot 👌

3

u/flyntspark Godot Student 1d ago

Listen to people when they say something is confusing! It's a path toward a better Godot 👌

And extremely relevant to games. Lending a sympathetic ear to complaints helps focus in on things that might need improvement.

6

u/dancovich Godot Regular 1d ago

This is the type of issue where their decision only makes sense when you're on the other side of the problem.

Sharing should be the default, period. Resources are meant to be shared and most of the time that's what you want to do

The solution needs to be a little more complicated. They could have a list of resource types most likely to not be shared and then, when you duplicate a node, it asks if you want to duplicate or share these resources.

1

u/huntsweez 1d ago

The problem is how embedded resources are just as much shared by default as seperately serialized ones. 

I don't think most users expect gd script files or textures to be made unique by default. But if you create a CollisionShape object and give it a shape resource (embedded by default), then duplicate the CollisionShape object, intuitively most users expect the duplicated unique object to also have a unique shape.

Godot further makes this worse by not communicating in the Inspector when a Resource is shared or not. And also does not provide a simple one click solution in the context menu to make a deep copy of an object making embedded objects unique.

2

u/dancovich Godot Regular 22h ago

Godot further makes this worse by not communicating in the Inspector when a Resource is shared or not

I think that's the worse issue. A system like blender that indicates how many "users" a resource has right next to the link would be nice, with a button to make it unique

1

u/huntsweez 11h ago

Yeah this would alredy improve the situation by a lot!

9

u/dinorocket 1d ago

No, the default behavior should be sharing. Making a bunch of duplicates and then realizing later on that you unintentionally bloated your project with a massive amount of extra resources would be much more painful, and also probably go uncaught in many cases since you wouldn't see the behavior change, you just end up with a much larger project and not know why.

Once you get used to it it's pretty straightforward to remember to make your resources unique.

7

u/therealnothebees 1d ago

Why is this even an issue for you? Make 10 different scene files for all plants, put them in the level scene, duplicate them around.... Why would you copy and paste the same asset around and modify it without making scenes for each variant...?

2

u/trickster721 1d ago

I think some people might be used to working with tools like Photoshop, where you aren't necessarily ever thinking in terms of shared/linked assets. So yeah, they're essentially complaining that it's too difficult to make ten unique copies of the same tree, which is a bit misguided, but I can see how some people might just want to copy-paste everything and ignore project structure. That's how most art works.

3

u/therealnothebees 1d ago

I mean, I've been using graphics programs since 1994 on the Amiga and Deluxe Paint 2.... Through the early versions of Photoshop back then, I work as an art lead and I don't see why would I ever want to ctrl c/v things in an engine instead of duplicating them, this is a good thing that it doesn't work like people expect and learned in programs that are not equivalent, cause they have to look for the proper solution now and that would be to make proper scenes/prefabs (if this was unity) and duplicate those.

Tbh I also blame teaching, I teach Unity gamedev and 3d modelling and artists who come in have zero tech art skills, they've only ever been taught their 3d package and substance, don't know how to pack uvs for lightmaps, don't know how to make assets efficiently - haven't been taught about hotspotting or using trim sheets and atlasses, weighted normals and a million other things... how to properly create your prefabs in Unity among them so they just throw fbx files from the assets directly into the scene, unpack them sometimes breaking links to the original model hierarchy, and then the same sort of messyness applies to Godot....

11

u/Agreeable-Owl-1514 2d ago

Please use git for source control, will help you out in the long run. Super easy to use

3

u/_michaeljared 2d ago

Edit: my gripes are specifically with GLTF importing. I think other parts of the resource saving system in Godot are fine.

100% agree. There is a pretty deep design flaw here. I have been saying it for a long time and it's why making pipeline tools is painful (even with GLTFDocumentExtension).

Most developers skip this altogether, and never drag .GLTF files into a scene. I think I saw Brackeys promote this idea the most, that we should import .gltf files into our engine, then extract meshes/textures/animation files as necessary, and then re-integrate them into scenes piecemeal.

This workflow works way better than having to hit "Make Local" on an imported gltf scene.

1

u/huntsweez 1d ago

You are talking about breaking the file-link between the imported resource in Godot and 3D authoring software. This sounds similar, but is a seperate issue.

1

u/_michaeljared 3h ago

You're right, I'm thinking of the "Make Local" function. Maybe I will make a post about that lol.

3

u/trickster721 1d ago

Here's the problem - which resources should be automatically duplicated? Collision shapes, sure. How about materials? Images? PackedScenes? Everything is a resource! They all depend on each other, so how many levels deep should it go? Picking resources to duplicate automatically is more complicated than it sounds.

2

u/Gabe_Isko 1d ago

It's because most people are using godot with source control, so discarding changes like this when you make this kind of mistake isn't that painful.

I agree, the editor interface isn't great, and it would be great to have a feature where godot saves a backup in ram or a dedicated backup folder or something that you can roll back to, but it isn't that bad to get into the habit of checking the make local to scene box. Just another quirk to using godot.

2

u/cheezballs 1d ago

Well it sounds like you actually needed a dedicated Tree scenne that can swap out the mesh onReady with a random one rather than hand-crafting each instance by hand in the editor.

If you're clicking it in the editor, chances are you can do it in code much easier.

2

u/TheSnydaMan 1d ago

I think this is a bit more of a workflow issue than anything, but also could be helped by some clarity in the UI.

Instead, make your workflow involve the actual file explorer- copying scenes there does not do so by reference. Make all your custom scenes there and drag them in instead of copying them in the viewer

2

u/Lucrecious 1d ago

When I used Godot, I found it much easier if I used nodes to hold information that needs to be copied instead of resources.

In your plant example, it sounds like you use resources to store the mesh and gradient colors. Instead, you can use export variables with nodes for the mesh and the colors themselves for the gradient rather than the gradient itself.

Since nodes are actually duplicated, changing their export variables gets the behavior you want without ever thinking about "Make Unique".

2

u/moongaming Godot Regular 1d ago edited 1d ago

This definitely needs to be revamped for clarity.

I got used to pretty much everything in Godot including the import process which is tedious but this still happens to me once in a while (editing a duplicate which changes the original)

I think a simple message when you first change a duplicated resource like "The change you are applying to this resource will also be applied to: XX would you like to make this resource unique?" would be a great way to at least remind the user that he's not editing a single instance.

2

u/HoveringGoat 1d ago

surely you can just pull the other instance from git history right?

2

u/haikusbot 1d ago

Surely you can just

Pull the other instance from

Git history right?

- HoveringGoat


I detect haikus. And sometimes, successfully. Learn more about me.

Opt out of replies: "haikusbot opt out" | Delete my comment: "haikusbot delete"

1

u/meneldal2 1d ago

People using version control correctly? in game dev?

1

u/imafraidofjapan Godot Regular 1d ago

You don't even need to use it "correctly". You just need to use it period. Commit a big ass blob daily, push to remote, and at least you have that history.

1

u/HoveringGoat 1d ago

could even skip the push to remote part qq

2

u/[deleted] 1d ago edited 1d ago

Hey, first of all I get your pain bc I've suffered from it a whole lot! Like I use Resources for Dialogue (which is not uncommon) and I duplicate nodes a lot, so imagine Losing a bunch of NPC cutscene in one go because they were linked. 

Also, I believe this is a huge UX issue. You 

a) can't fell if a resource is shared (difficult tracking)

b) even if you actually made the thing unique, some stuff don't get duplicated by the editor (for instance, Arrays and Dictionaries with Resources)

This might be a non issue for a lot of people, but to me it was a dealbreaker (got tired of losing data when I supposedly made it unique). 

For that Reason I decided to work on 2 PRs to solve a) and b)! 

https://github.com/godotengine/godot/pull/109458 https://github.com/godotengine/godot/pull/109816

I know this is a non issue for a lot of people (as seen in the comments) but you can't tell how I'm glad hearing someone talk about it.

TLDR: Yeah it's such a pain I ended up trying to solve it

2

u/nonchip Godot Regular 1d ago

because you're copypasting stuff all over.

2

u/Etruscian 1d ago

The biggest issue I have with this is that the Godot editor allows for creating and editing resources without saving them explicitly. The saving is done implicitly in the parent object, which causes confusions like the one from OP. I would love to see this confusing feature removed entirely.

Imo, if you want something reusable, create a resource and save it to the file system. If something is specifically meant for one node only, why go through the hassle of using a resource and export the variables you need to edit directly from the script. Things like meshes and shaders are used in generic objects, which are reusable, so the meshes and shaders should be resources saved to the file system.

2

u/MikeyTheGuy 1d ago

Sorry but I emphatically disagree. The alternative would end up being much worse (tons of unnecessary resource files everywhere).

Your problem can easily be solved by saving the Resources themselves as separate standalone files.

1

u/huntsweez 1d ago

I think the problem would be solved if embedded resources are made unique when the object is duplicated. Noone expects a gd script file to be uniquely duplicated or a textrue if the object using them is duplicated. But with embedded resources (a shape resource of a CollisionShape object for example) this is different.

If Godot keeps sharing all resources, embedded or not, then at least give us a duplication method to duplicate embedded resources unique. And a UI indicator in the inspector which resource is shared and which is not.

2

u/Ok_Finger_3525 1d ago

It is not painful if you engage with the system in the intended way. It is painful if you ignore it.

2

u/huntsweez 1d ago

This issue has caused me so much extra work. It's Godots biggest pitfall.

The solution would be so simple. Have two UI Buttons instead of one:

  • Duplicate (shared)
  • Duplicate (unique)
And a clear UI indicator right next to the Resource in the inspector to visualize how many Objects use the resource. Like a small number.

2

u/davidcabreragarcia 1d ago

I think shuold be some different keys to make this like in blender alt+d to duplicate linked and shift+d to make it unique by default

2

u/Wonderwall_1516 1d ago

This is by far my biggest pain point as well.

It's something I just don't remember until I look at the thing I copied and see it's way messed up.

1

u/emertonom 2d ago

I definitely got caught by something similar yesterday. I'm still new at this. I was trying out using AnimationPlayer instead of AnimatedSprite2D, and wanted to try adjusting the collider to match the visual changes in the sprite. Which was working fine initially, but then when I added a few of my guys to my test scene, suddenly they were jittering all over the place. It took me quite a while to figure out that the issue was that when the AnimationPlayer was adjusting the properties of the collider, it was doing so on a shared resource, the Shape object. All the instances of the enemy, regardless of what animation state they were in, were having their collider adjusted all the time by all the other instances. As soon as I set it to duplicate the resource in the ready function, the issue vanished.

I guess it's just another thing to get used to, though.

1

u/yezu 1d ago

I think the feature and functionality are ok and very useful. You do want for things to share resources when things are to shere visuals or behaviours.

The biggest problem IMHO is that it's unclear when that is the case. I think resources that are shared or unique should be clearly marked in the UI somehow.

1

u/x-sus 1d ago

Okay so hknestly... It was annoying for like a week then became a huge strength in my eyes. I only save my resources(because it sounds insane to have a billion resources if the settings wont be reused) when I need to but remember to make them unique when I need to.

BUT...I have a potential fix for you. Try saving the finished new version as a resource, then go into the file system, copy it and paste it in another location outside of your project. Then ctrl+z your way back to conformity. And when its all good, drag the copied version back into godot, and then back onto your thing(plant or mesh or whatever).

Its not a super great fix but its definitely an option.

Also, it would be great if when you start editing a shared resource if it popped up a thing that says "this resource is used on multiple nodes - be warned" or something.

1

u/Foreign-Radish1641 2d ago

I agree. Maybe it should ask whether you want to paste by reference or by value when you paste a resource in the inspector.

1

u/Level-Lab-9312 1d ago

I find it annoying too. So much so I stopped duplicating and make everything from a new scene every single time.

2

u/HunterIV4 1d ago

This is frankly what you should be doing anyway. Duplicating is fine for prototyping or manual instancing, but if you want long-term variants, they should be individual scenes.

Using scenes with @export resources for values that change is a far more robust and scalable solution than duplicating in some random node tree and hoping you find that object to duplicate again later in the right spot.

1

u/DaisyGamesStudio 1d ago

Source control saved my butt in these cases so many times...

1

u/Yacoobs76 1d ago

I agree with you 💯%

-1

u/NoGuidance2123 2d ago

Nitpicking