Revert turf signal preservation + open_space tweaks

[Drulikar]

About the pull request

This PR partially reverts #11864 because of issues discovered when testing #12434. Basically the problems with the turf signal registration are:

• They aren't even implemented correctly, just a LAZYOR is insufficient to replicate the (unnecessarily) complex series of associated lists
• Its not feasible to account for all sideeffects that may occur during the Newing of a turf that make all previous signals correct to copy over
• I think it generally more clear to expect things to explicitly implement themselves entering into a new turf than the reverse (side effects that could affect some unrelated signal that just happens to be caught in the crossfire)

Of note moveable atoms (obj inherit moveable) can just register themselves to COMSIG_MOVABLE_TURF_ENTERED to detect a self turf change because Entered will be called when the turf is New'd. turf/Entered() is now set it must call parent because that is where the signals are called.

As far the open_space changes, they appear to be the only turf that Initializes that doesn't call parent, so weren't calling Entered on its contents until now. This then caused issues in the test room, so adjustments were made to accomodate for that as well as an assertion for their placement generally. Even if placed wrong though, mobs aren't allowed to be force moved to null, and attempting to climb them already says its too dangerous.

Explain why it's good for the game

Less runtimes (just about signal registrations lacking override) and hopefully correct signals that aren't messed up just by turfs changing. Also better open_space handling & assertions.

Testing Photographs and Procedure

Generally this is a return back to how things were, but I did test say how tents handled turfs changing to ensure all of their locs would trigger an Enter (and they do), as well as moving/exploding/changing turfs under a corpse (to test weed_food), and multiz stairs. See below:

Screenshots & Videos

Late spawned stairs:

Changed 3 turfs for late spawned stairs, and moved north, and stairs-up effects still triggered as normal:

More tent testing:

2026-06-25.17-00-32.mp4

Changelog

🆑 Drathek
del: Removed logic making turfs persist signals
fix: open_space now calls Entered for atoms in its contents on Initialize (making them fall automatically)
code: open_space now checks placement is valid when testing and doesn't attempt to forcemove anything out of the map
/:cl:

[Drulikar]

May need to figure out why weeds were being handled in a very particular way, not able to currently find what may have needed the special treatment.

[fira]

Things like the tents are also going to need a ChangeTurf signal handler to work properly

I think when i wrote them i incorrectly believed the turf signals already did stick, even though it was added much later

[fira]

Why? Tents weren't meant to be moved at all, if they are it's going to need more work than that

[Drulikar]

See pr description:

Of note moveable atoms (obj inherit moveable) can just register themselves to COMSIG_MOVABLE_TURF_ENTERED to detect a self turf change because Entered will be called when the turf is New'd. Enter is now set it must call parent because that is where the signals are called.

They already handle turf changes because of what you're confused about.

Just added a video to testing section to display this too.

[fira]

Oh ewww but there should be a specific signal for ChangeTurf, i guess we just don't have it?

[Drulikar]

The specific ChangeTurf signal is via callback creation with a COMSIG_PRE_TURF_CHANGE. See implementation of staircases in this PR. Its just less work to use COMSIG_MOVABLE_TURF_ENTERED when applicable (something that is a moveable atom, and cares specifically about something in its loc/locs). If you care we could rename that signal to something more obvious if you have something in mind? But literally its the thing entering the new turf. The only non-obvious aspect is whether changeturf triggers entering (it does).

Before their optimization pr #11864 the logic at the end of a changeturf was this:

for(var/atom/movable/thing as anything in W.contents)
	SEND_SIGNAL(thing, COMSIG_ATOM_TURF_CHANGE, src)

And they were avoiding this because of the perf.

[Drulikar]

Updated the signal's autodoc and fixed the single occurrence of a turf Initialize that didn't call entered on its contents.

[fira]

No i mean there is a specific ChangeTurf signal that is done at the moment of swapping it. On /tg/ it's COMSIG_TURF_CHANGE. It's what you'd want to use in this case, I believe.

[Drulikar]

Their COMSIG_TURF_CHANGE is our COMSIG_PRE_TURF_CHANGE which I already described to you above.

The specific ChangeTurf signal is via callback creation with a COMSIG_PRE_TURF_CHANGE. See implementation of staircases in this PR. Its just less work to use COMSIG_MOVABLE_TURF_ENTERED when applicable (something that is a moveable atom, and cares specifically about something in its loc/locs).

---

TG vs our implementation of that signal (same just different name - ours more descriptive):
https://github.com/tgstation/tgstation/blob/3c8146f59e5cfe79a80950201a4c0a635758c2a2/code/game/turfs/change_turf.dm#L101-L105
vs

cmss13/code/game/turfs/turf.dm

Lines 495 to 499 in e08f9aa

	var/list/post_change_callbacks = list()
	SEND_SIGNAL(src, COMSIG_PRE_TURF_CHANGE, path, new_baseturfs, flags, post_change_callbacks)
	changing_turf = TRUE
	qdel(src) //Just get the side effects and call Destroy

---

And the difference between implementations of one signal vs the other:

cmss13/code/game/objects/structures/multiz_stairs.dm

Lines 152 to 165 in e08f9aa

	if(length(from_turf_to_images[from_turf]))
	RegisterSignal(from_turf, COMSIG_TURF_ENTERED, PROC_REF(handle_entered), override=TRUE)
	RegisterSignal(from_turf, COMSIG_PRE_TURF_CHANGE, PROC_REF(handle_pre_turf_change), override=TRUE)
	/// Handler for COMSIG_PRE_TURF_CHANGE to set post_change_callbacks
	/datum/staircase/proc/handle_pre_turf_change(turf/source, path, list/new_baseturfs, flags, list/post_change_callbacks)
	SIGNAL_HANDLER
	post_change_callbacks += CALLBACK(src, PROC_REF(re_register_from_turf_signals), source)
	/// Re-registers the COMSIG_TURF_ENTERED and COMSIG_PRE_TURF_CHANGE for handle_pre_turf_change
	/datum/staircase/proc/re_register_from_turf_signals(turf/new_turf)
	SHOULD_NOT_SLEEP(TRUE)
	RegisterSignal(new_turf, COMSIG_TURF_ENTERED, PROC_REF(handle_entered))
	RegisterSignal(new_turf, COMSIG_PRE_TURF_CHANGE, PROC_REF(handle_pre_turf_change))

vs

cmss13/code/game/objects/structures/multiz_stairs.dm

Lines 6 to 23 in e08f9aa

	/obj/structure/stairs/multiz/Initialize(mapload, ...)
	. = ..()
	RegisterSignal(src, COMSIG_MOVABLE_TURF_ENTERED, PROC_REF(register_with_turf))
	if(!mapload)
	register_with_turf()
	for(var/turf/blocked_turf in range(1, src))
	blockers += WEAKREF(new /obj/effect/build_blocker(blocked_turf, src))
	blockers += WEAKREF(new /obj/structure/blocker/anti_cade(blocked_turf))
	return INITIALIZE_HINT_LATELOAD
	/obj/structure/stairs/multiz/Destroy()
	QDEL_LIST(blockers)
	return ..()
	/// Handler for callback of COMSIG_MOVABLE_TURF_ENTERED if we're moved (turf changed)
	/obj/structure/stairs/multiz/proc/register_with_turf()
	SIGNAL_HANDLER
	RegisterSignal(loc, COMSIG_TURF_ENTERED, PROC_REF(on_stairs_moved))

[fira]

Ah my bad. I thought it was called at a different time for some reason...

What my concern boils down to is essentially that using COMSIG_MOVABLE_TURF_ENTERED and COMSIG_TURF_ENTERED to piggyback on /turf/Entered behavior for ChangeTurf also gives the impression that (in this example case for tents) the case of movement is handled, which is not the case. Older signals are not Unregistered, both turfs and contents, and the tent as a whole does not properly support being moved.