any option to have [GetComponent] not override user set reference?

[laurentopia]

I'd like to use [GetComponent] to auto set a default value that can be overridden by the user.
But GetComponent overrides user value.
Is there a way around that?

[TylerTemp]

Hi,

this is now possible in 3.4.0:

[GetComponent(EXP.Silent | EXP.NoPicker)] public Dummy issue72Dummy;
[GetComponent(EXP.Silent | EXP.NoPicker | EXP.NoResignButton)] public Dummy issue72DummySimple;

The config is kinda tedious. It might be optimized on a later version.

Note: This update might contain bugs.

[laurentopia]

is it X or the cycling button? in the other post it was an X so maybe I don't understand its purpose

[TylerTemp]

Hi,

"X" means the value is manually signed, but the Get* attribute actually find nothing, so a "x" will allow you to remove the value.

"Reload" means the value is manually signed, but the Get* attibute find a value which is different from the current value, so a "Reload" will allow you to sign to a "correct" value, rather than the "current" value.

And EXP.NoResignButton will completely hide these buttons.

[laurentopia]

this isn't working

equHKb88Qt.mp4

[TylerTemp]

Hi,

To use this feature, you need to at lease set EXP.Silent:

// simple
[GetComponentInChildren(EXP.Silent)] public MCMineable source;
// no picker button, no resign/remove button
[GetComponentInChildren(EXP.Silent | EXP.NoPicker | EXP.NoResignButton)] public MCMineable sourcePlain;

Unity_6P8yr3lWNK.mp4

---

I do plan to make a config function to set default config globally for many attributes. But that will be much later, after I finish some important features first.

[laurentopia]

Ok. Why silent? Seems like a good default behavior.

[TylerTemp]

Well, I can not give a good reason.

When I design GetComponentByPath, which was originally designed to be the parent of all the auto-getter attributes, it behaves exactly like Silent. I'd like to think of it as a good design.

When I refactored it into GetByXPath, it took way too much time than I expected. When on its final touch, I actually lost track of which should be the default behavior.

When I'm working in the company, one thing I need to do constantly is: to re-bind all the lost references after a code merge. Yep, we decide not to merge the Unity scene because it's just not possible: Unity has a so-called yaml-merger, and it sucks. So whenever I merge the scenes, I just throw away my scenes and manually add everything back into the remote one. After manually adding the object & script, then is the magic part: because the auto-getter attributes will aggressively sign the value to the "found" value, all my setup will be correct, with no need to manually click the "re-sign button".

So, with not enough thought, I picked that aggressive behavior as the default. And I regret it...

Yep, that's the story. That's also why I plan to support a config file to allow to change of the default behavior globally (like what DOTween does).

[laurentopia]

oh boy, it's like thinking of a name for a method then you're stuck with a naming convention...

[TylerTemp]

Ok. Why silent? Seems like a good default behavior.

Hi,

Since 3.4.11 you can use Window/Saints/Create or Edit SaintsField Config to tweak the config of the default behavior of auto getters.

[laurentopia]

Cool, I was just running into default collision!

[laurentopia]

just updated to 3.4.11 and I'm running into this new bug.

Maybe this accessor was added after 2020

[TylerTemp]

just updated to 3.4.11 and I'm running into this new bug. Maybe this accessor was added after 2020

Hi,

Can you copy paste the error? Looks like some issue with reading the config file

Also can you check "Assets/Editor Default Resources/SaintsField/SaintsFieldConfig.asset", can it be correctly displayed?

[TylerTemp]

Oh holy fuck... your version is indeed a bit low that does not have ManagedReference yet

I'll fix it soon

[TylerTemp]

Sorry for the trouble, it's been fixed in 3.4.12

[laurentopia]

No worry, I needed to go to bed anyway :D