PackedScene: Avoid saving signal connections twice

[cixil]

Fixes #48064 and fixes #86532

When packing a tree of nodes to a PackedScene, signal connections originating from the root node of a scene instance within that tree would get duplicated into the PackedScene and cause "duplicate signal" errors when instantiating it.

---

I originally made PR #97303 which was partially reverted by #100235 because it inadvertently caused #100097.
This fixes #48064 without causing #100097 using @KoBeWi's suggestion from 100097.

It changes the line committed in #66289 which fixed #66154 to use GEN_EDIT_STATE_MAIN instead of GEN_EDIT_STATE_INSTANCE, I've verified this change does not reopen #66154

[cixil]

@akien-mga

[cixil]

My understanding of the code (which could be wrong) is that this line is calling instantiate on every packed scene in the game as part of some necessary processing when exporting the game to a binary file. Since we are just processing the scenes alone by themselves, it makes sense to use GEN_EDIT_STATE_MAIN instead of INSTANCE here.

The CONNECT_INHERITED flag is applied here depending on the GEN_EDIT_STATE

godot/scene/resources/packed_scene.cpp

Line 609 in aa8d9b8

cfrom->connect(snames[c.signal], callable, CONNECT_PERSIST | c.flags | (p_edit_state == GEN_EDIT_STATE_MAIN ? 0 : CONNECT_INHERITED));

I believe passing GEN_EDIT_STATE_INSTANCE to instantiate was applying the CONNECT_INHERITED flag falsely to signal connections and saving them. It was not game breaking, so went unnoticed.

But by changing the GEN_EDIT_STATE here, we can use the CONNECT_INHERITED flag to correctly process signals when packing a scene.

But this should be verified by someone more familiar with the engine.

[RandomShaper]

It's hard to be 100% sure about the implications without detailedly debugging all this myself, as it's long since I last touched this code, but I'd say your logic is good.

The use of GEN_EDIT_STATE_INSTANCE was in fact discussed (see 6973abd). The reason stated there for prefering it was a bit weak. and there wasn't a strong preference for either. Now we have a solid argument to back why GEN_EDIT_STATE_MAIN is preferable. I agree with you that it's the right choice in this context, where the scene is being instantiated in a standalone fashion, which warrants it to be treated as the main one.

[RandomShaper]

Somehow TIWAGOSly, I'm leaving my approval as the changes look good to me and I gues it will help keep things moving forward. It'd be great to have this thing covered in tests, though.

[akien-mga]

Could you amend the commit message to formatted like a normal sentence/commit title? E.g. like this PR's title.

[cixil]

This and #97303 added tests to make sure signals are saved properly by PackedScene's pack function.

I wanted to add a test for the GEN_EDIT_STATE_MAIN thing, but I had no idea how to approach that, as I couldn't find how exports are tested.
The test would need to verify that signal connections are present in exported projects in addition to the issue in #66154

[KoBeWi]

This causes the issue I mentioned in #100097 (comment)
In my plugin I remove part of the scene, pack it and then re-instantiate (sort of built-in PackedScene). This PR makes the signals stripped with this operation.
MRP:
Brokensignals.zip
Open the Bug bottom panel and click the buttons.

I'm not sure how this could be resolved though. Maybe don't apply CONNECT_INHERITED when edit state is 0? Though it's such a corner-case that it's probably not blocking this PR.
My workaround is manually stripping the flag from signals. It's unexposed though, which makes it even more hacky.

[cixil]

This causes the issue I mentioned in #100097 (comment)

I feel like its better practice to save the button as a separate scene and just instantiate that, which solves the issue. Unless that somehow doesn't work for your original use case

@export var button_scene:PackedScene
...
	for i in 10:
		add_child(button_scene.instantiate())

---

But I'd hate to break something else by fixing something. This probably deserves a little bit more testing to see if this case affects any other scenarios before its merged.

[cixil]

Did #100160 solve this case?

[KoBeWi]

Yes.

I feel like its better practice to save the button as a separate scene and just instantiate that

The point is to avoid excessive scenes, like with built-in scripts. It's a niche use-case though, so it's something that can be fixed later (or not, as there is workaround).