Characters don't get deleted when changing rooms

[balloonpopper]

Bug description

Characters don't get deleted when changing rooms and appear in the next room when they haven't been included in that room.
It is related to the room not having the "Script name" property set.

Steps to reproduce

Have 2 rooms where RoomA connects to RoomB. RoomA should have some characters added to it. RoomB should not have the characters added to it.
Do not set the "script_name" for the parent node of either room.
Play the game and go from RoomA to RoomB, the characters from RoomA will be instantiated in RoomB.

Expected vs observed behavior

Characters shouldn't appear in a room they haven't been included in.

Environment information (please complete):

• Windows 10
• 4.4 dev 3
• Latest popochiu dev commit

Additional context

After some investigation, what appears to happen is that this code runs in the goto_room function (i_room.gd): (line 166)

	if store_state:
		rooms_states[current.script_name] = current.state
		current.state.save_children_states()

If the parent node of the room does not have a script name set, then it gets the value of the destination room. This means that if you're going from RoomA -> RoomB, this store state code stores RoomA's state in the dictionary 'room_states["RoomB"]'. Afterwards, when RoomB is instantated, the code in the "room_readied" function runs and the code on line ~239-255 recreates RoomA's characters in RoomB.

	for chr_script_name: String in rooms_states[room.script_name]["characters"]:
		<...>
		current.add_character(chr)

[stickgrinder]

@balloonpopper sorry for the lag.

I'm going to close this without fixing because we can't accept bugs on a non-supported version of Godot.
In the past we notices that working with dev engine versions shown bugs that eventually disappeared at a later stage of Godot development.

Thanks for taking the time to report, and work this around but we'll face the problem when we'll port the engine to 4.4 stable.

[balloonpopper]

@stickgrinder - I disagree with the closing of this ticket. Why didn't you just ask if I could confirm it in 4.3 instead of closing it?

This should be reopened. I have just tested this in 4.3 and this is still a valid bug. When travelling between 2 rooms without script names associated with them, characters from the first room appear in the second room when they shouldn't.

In fact, it's more than just characters. all these errors appear when I go from the first room to the second room. They are all things in the first room that should get deleted when entering the second room.

[stickgrinder]

@balloonpopper we gave for granted that the problem was with that version of Godot because you mentioned it, and it's not clear how a room can be created without a script name in the current supported version.

Can you please make clear how this step to reproduce the bug came to be in your context?

...
Do not set the "script_name" for the parent node of either room.
...

If that came out of the normal usage of Popochiu, then that's of course a bug.
Keeping @mapedorr in the loop, because it was him reviewing the original PR.

[balloonpopper]

I'm not sure how I ended up without a name for the script so can't help you there sorry. I used the normal tooling , but somehow ended up in that state. The user could potentially remove the script name themselves though, so addressing the symptom will automatically solve the issue of its an interface big, a Godot bug, or a user mistake.

…

On Tue, 24 Dec 2024, 01:02 Paolo Pustorino, ***@***.***> wrote: @balloonpopper <https://github.com/balloonpopper> we gave for granted that the problem was with that version of Godot because you mentioned it and it's not clear how a room can be created without a script name. Can you please make clear how this step to reproduce the bug came to be in your context? ... Do not set the "script_name" for the parent node of either room. ... If that came out of the normal usage of Popochiu, then that's of course a bug. Keeping @mapedorr <https://github.com/mapedorr> in the loop, because it was him reviewing the original PR. — Reply to this email directly, view it on GitHub <#345 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHJUCR2TURNU2FRW4OZV2L2HAJX5AVCNFSM6AAAAABR3D36KWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJZG43DMNJQG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>