Tripwires without tripwires

[ZylonBane]

As some of you may know, Dark's mantling code has a bug that can cause mantle attempts to fail if the player is inside a tripwire (probably because tripwires are technically physics objects). This normally isn't a problem since tripwires tend to be out in open spaces, or set to destroy themselves, but in some situations it very much can be a problem, like say a persistent tripwire in a pit that players can only mantle out of.

So I'm trying to think of a way to simulate the functionality of tripwires without actually using tripwires. This would have to emulate both Enter and Exit events.

My first thought was to replace the tripwire with a repeating stim source, with a receptron on the player that would bounce the stim back to the sender. A script would then listen for this stim and translate it into a TurnOn, and then use a timer checking for the sustained absence of the stim to generate a TurnOff.

But there are people here who've been using DromEd exponentially longer than I have, so I'm wondering if there's a better, less resource-intensive solution.

[vfig]

normally i would try to use room brushes for this, since they have reliable entry/exit events.

if theyre not an option, you could achieve this result with fewer moving parts than a stim setup with a script that measures distance to the player every frame, and sends TurnOn/TurnOff whenever the distance crosses a threshold. to avoid the overhead of running the script when the player is nowhere near the object, you could trigger the script from a Flicker tweq set to SimSmallRad (player is within 20 units) or SimLargeRad (player is within 80 units).

[ZylonBane]

Interesting, I hadn't thought of room brushes. Seems like that could potentially cause issues with audio propagation when placed as tripwires tend to be placed.

Well, I ended up going with the S&R setup. I figure the engine is far more optimized for figuring out when the player is near and sending a stim to it than any Squirrel code code be, and a stim lets me throttle how often it even checks. The Squirrel code then does a terrain raycast on initial activation to make sure it's not being triggered through a floor or ceiling, since it creates effectively a spherical rather than cuboid tripwire volume.

Biggest pain in the ass writing this was trying to figure out how to access the source object of a received stim. sLink(message().source).source, go figure.

// Tripwire substitute that uses stims instead of a tripwire. Use sparingly, only
// where a conventional tripwire prevents mantling.
// Required Setup:
// - Stim types TripwireTx and TripwireRx must exist.
// - Player archetype has receptron TripwireTx, No Min, No Max, Effect: Stim Object,
//   Stimulus TripwireRX, Target Source, Agent Me
// - Tripwire has source TripwireTx, Radius, Intensity 1, Radius 10 (or as desired),
//   No line of sight, No max firings, Period 200
// - Tripwire has receptron TripwireRx, No Min, No Max, Effect: Send to Scripts
//
// Usage:
// - On the problematic tripwire, set Physics/Misc/Collision Type: [None] (uncheck
//   everything). This will make the tripwire ignore player collisions, but still
//   inform AIs that they're allowed to open the door, and still generate TurnOff
//   messages to close doors behind AIs (AIs will only automatically open doors for
//   themselves, not close them).
// - Create a Stim Tripwire in the same location as the tripwire and switchlink it
//   to the door to be controlled.
class scpStimTripwire extends SqRootScript {
	function OnTripwireRxStimulus() {
		// don't send multiple TurnOn messages and don't trigger if stimmed through a floor or ceiling
		// (do a raycast from the tripwire to the return stim source)
		if (!GetData("LastOn") && !Engine.PortalRaycast(Object.Position(self), Object.Position(sLink(message().source).source), vector())) {
			Link.BroadcastOnAllLinks(self, "TurnOn", "SwitchLink");
			SetData("LastOn", true);
		}
		// keep restarting timer while player is in range
		// timer duration must be at least double the stim period
		if (IsDataSet("StimTimer")) {
			KillTimer(GetData("StimTimer"));
		}
		SetData("StimTimer", SetOneShotTimer("StimCheck", 0.4));
	}
	
	function OnTimer() {
		if (message().name == "StimCheck") {
			// timer completed, so player must be out of range
			Link.BroadcastOnAllLinks(self, "TurnOff", "SwitchLink");
			SetData("LastOn", false);
		}
	}
}

[vfig]

Interesting, I hadn't thought of room brushes. Seems like that could potentially cause issues with audio propagation when placed as tripwires tend to be placed.

not really. more of an issue is if you want a very small trigger area, then a room brush is not very convenient.

Well, I ended up going with the S&R setup. I figure the engine is far more optimized for figuring out when the player is near and sending a stim to it than any Squirrel code code be, and a stim lets me throttle how often it even checks.

the difference is negligible, unless you have thousands of these all active at once. and the Flicker tweq rate gives you throttling control too.

The Squirrel code then does a terrain raycast on initial activation to make sure it's not being triggered through a floor or ceiling

can't you just use the "line of sight (raycast)" flag on the stim source instead?

[ZylonBane]

can't you just use the "line of sight (raycast)" flag on the stim source instead?

Stims do an obj raycast, which can be blocked by the very door that the tripwire is controlling. Doing it in Squirrel allows specifying a terrain-only raycast. It also allows skipping the raycast entirely after the script has determined that the player has properly entered the bounds of the trigger.

[vfig]

Stims do an obj raycast, which can be blocked by the very door that the tripwire is controlling. Doing it in Squirrel allows specifying a terrain-only raycast.

ah, that makes sense. i wasnt aware that the stim raycast would hit objects.