Dragofer's Scripting

[Dragofer 1422]

As my custom assets work has increasingly shifted from models towards scripting, I'll open a new thread here to contain any scripts that I write which can be reused in other missions, starting with the

A ) Presence Lamp

This is a Lost City-style lamp that brightens and dims depending on the presence of the player or an AI. It fades between 2 colours and can trigger its targets whenever it switches fully on or off, so it should also be viable in various other situations.

The standard setup consists of the following:
- a trigger_multiple brush. The spawnarg "anyTouch" controls whether AIs, too, are able to activate it
- a presence lamp, highly recommended with a colorme skin
- one presence light, or any other light with appropriate spawnargs
The targeting chain is trigger brush -> lamp -> light

When the player or an AI stands in the trigger_multiple brush, the lamp switches on and starts a short timer. Subsequent triggers reset the timer. If the timer runs out because no one's standing in the trigger brush anymore, the lamp switches itself off.

Notes

- Multiple trigger brushes can target the same lamp, and one trigger brush can target multiple lamps. However, each presence lamp can only target one light, so if you want i.e. a bouncelight you'll need to hide an additional silent presence lamp somewhere and target it from the same trigger brush.

- The lamp and the light use their own colour spawnargs respectively, since setting 0 0 0 on a lamp would make it appear pitch black.

- Technically the trigger brush can be exchanged for anything else that triggers the lamp every 0.5s (this number can be changed via "update_interval" on the lamp), i.e. a trigger_timer.

- This was originally named the proximity lamp and was one of many scripting jobs for The Painter's Wife. I've renamed it to "presence lamp" because the mapper may place the trigger brush(es) wherever he wishes: proximity to the lamp is not a factor. Credits go to Bikerdude for putting together the crystal lamp models.

Download

Presence Lamps - Google Drive

Place or extract the .pk4 into your FM archive, then look up the presence lamp prefabs. If you already are using other custom scripts, remember to add the presence lamp's .script to your tdm_custom_scripts file.

 

B ) Teledoor

This is a Skyrim-style door which opens just a bit into a black_matt "void" before teleporting the player to a different area of the map, which may represent the other side of the door. This is used for connecting physically separated map areas with each other, such as when there's an exterior/interior split of a building or ship to allow for more mapping freedom.

[Full Thread]

 

C ) Mass Teleport

This is a teleportation setup designed to seamlessly teleport the player and any moveables between two identical-looking areas. This allows the mapper to link 2 physically distant areas with each other while maintaining the illusion that they're connected. The teleportation zones should be free of AIs as they can't be teleported like this.

[Post]

 

D ) Automaton Station

A station for Sotha's automatons (includes the automatons) which can be switched on and off by patrolling automatons.

[Post]

[Automaton Station]

 

 

[Bienie 424]

Loving that presence lamp setup! That could be very useful to mappers. I've wanted to make a lost city style map for a long time, and that is one piece that I wouldn't have to worry about, should I pursue that idea!

[VanishedOne 546]

When I tried to make Lost City lamps with trigger_inactivity, I found it worked for the player but the trigger_multiple would repeatedly trigger its target with an AI inside it only if the AI was pathing, not if it was standing still. Have you found differently?

[Obsttorte 1513]

@VanishedOneThat's indeed the case. Note that Dragofer doesn't directly triggers the light via the trigger_multiple, but instead uses it to reset a timer that turns the light off once it ran out.

[VanishedOne 546]

Right: that's basically what I did as well. If the AI stood still for long enough the timer would run out and the AI would be plunged into darkness. If memory serves, the last time I mentioned this you suggested using a different set-up with a modified AI scriptobject.

[Dragofer 1422]

I can confirm that trigger_multiple brushes stop firing triggers if an AI stands still within them. So I see 3 options:

1. Report this for 2.09 so it hopefully gets fixed, or keep both mechanisms so we have both motion sensors and presence sensors.
2. Develop a different presence mechanism that doesn't (wholly) rely on trigger brushes
3. Turn this into a feature and rename to  "motion lamp" instead of "presence lamp". Change the script so the lamp only responds to player movements that exceed a certain velocity.

[VanishedOne 546]

I favour (1) unless there are technical reasons not to, because it would remove a disparity between how AI and the player are treated by the trigger.

[Abusimplea 168]

If it is possible to use stim/response for proximity detection, binding something emitting a special stim would allow for detecting the proximity of an AI while standing still.

[Dragofer 1422]

Posted to the bugtracker:
0005319: Trigger_multiple stops working if AI stops moving

[Obsttorte 1513]

You could check whether ai emit a visual stim, they player should. The lamps could than do a proximity test. Otherwise a custom stim applied to the ai could serve the purpose. It would probably good to allow both versions, either by using a trigger to control the lamp or the stim variant.

19 hours ago, Dragofer said:

Turn this into a feature and rename to  "motion lamp" instead of "presence lamp". Change the script so the lamp only responds to player movements that exceed a certain velocity.

You could basically have both. If the minimum velocity needed for the lamp to turn on is controlled via a spawnarg, mappers would have the choice to set it to zero if the want a "presence lamp". A "motion lamp" could be interesting in respect to gameplay. Besides the magical lamp type of Lost City style one could also think of such lamps in manor missions or similar, whereas those are something by the inventors guild. Sneaking by lamps that go on if you are to fast while there is ai around could create quiet some tensive moments.

[Dragofer 1422]

A motion lamp should be quite feasible if I can get trigger_multiple brushes to inform the script who activated it. Trigger_touch has such a function (pass_activator and pass_self spawnargs) but I don't see that for trigger_multiple. Surely that possibility exists?

For making stim-triggered presence lamps, a problem will be that the radius of the stim is defined on the humanoid and not on the lamp, and any existing stims might be too short-ranged for general use. Would likely need to put custom stims with a large radius on all AIs and the player and only let the lamp react if the humanoid is within a certain spawnarg-specified radius. Alternatively each lamp lamp could check every second whether it can see someone, though then it'd frequently switch on/off when the player or AI moves around objects that provide cover.

Another potential problem is that the AI might be very close but on a different floor/in an adjacent room. Visibility checks can't be used to identify this because the humanoid might be hidden behind cover, so it'll have to be location-based: each room should be its own location. Looks like this is a more involved route than the trigger brush method.

[Obsttorte 1513]

Even if a stim is used to initiate the lamp behaviour, you can specifically define on how you want to do the detection. So to mimic the trigger behaviour (assuming you are using cuboid shaped triggers) you could do a coordinate check (via mins/maxs as done by some entities for example).

To apply the custom stim you only have to modify the ai_base and player_base definitions. So you don't have to add the stim to all affected entities manually.

[Dragofer 1422]

Here's a .pk4 containing @Sotha's great automaton guards from Ulysses: Genesis as well as an alternative design for the charging station that I had already made on another occasion, as requested by @JackFarmer. The reason I'm posting this in my scripting thread is that I've made a straightforward scriptobject for the charging station, allowing an automaton to switch it on and off as part of its patrol, thereby saving a lot of money on the lord's electricity bill and preventing the station from getting out of sync. It also switches off after a specified time (time_max), in case the automaton is destroyed while it was charging.

Mapping wise, it works by having path_anim nodes activating callobjectfunctions, calling either station_on or station_off on the station. The station toggles its targets, unless it's already in the desired state. Prefabs can be found under prefabs/mechanical/automaton_station.

Here's the simple scriptobject:

Spoiler

object automaton_station
{
	void	init();
	void	station_on();
	void	station_off();

	//INTERNAL
	float	m_station_state;

	//SPAWNARGS
	float	m_time_max;		//station automatically switches off after this time if bot fails to switch it off (i.e. because it's been killed at the station). 0 = infinite.
};


void automaton_station::init()
{
	m_time_max		= getFloatKey("time_max");
}

void automaton_station::station_on()
{
	if(!m_station_state)
	{
		activateTargets(self);
		m_station_state = 1;
	}

	if(m_time_max)
	{
		sys.wait(m_time_max);
		thread station_off();	
	}
}

void automaton_station::station_off()
{
	if (m_station_state)
	{
		activateTargets(self);
		m_station_state = 0;
	}
}

 

Under the hood, I've taken the opportunity to clean up the assets a fair amount, trimming unused components and ensuring it follows TDM's conventions, which is a necessary step towards an inclusion in the core assets.

The download can be found in section D of the original post.

[JackFarmer 482]

That's my boy, thank you for your quick help!

Jack

 

 

 

 

 

 

Edited October 3, 2020 by JackFarmer

[HMart 334]

On 10/3/2020 at 1:30 PM, Dragofer said:

Here's a .pk4 containing @Sotha's great automaton guards from Ulysses: Genesis as well as an alternative design for the charging station that I had already made on another occasion, as requested by @JackFarmer. The reason I'm posting this in my scripting thread is that I've made a straightforward scriptobject for the charging station, allowing an automaton to switch it on and off as part of its patrol, thereby saving a lot of money on the lord's electricity bill and preventing the station from getting out of sync. It also switches off after a specified time (time_max), in case the automaton is destroyed while it was charging.

Mapping wise, it works by having path_anim nodes activating callobjectfunctions, calling either station_on or station_off on the station. The station toggles its targets, unless it's already in the desired state. Prefabs can be found under prefabs/mechanical/automaton_station.

Here's the simple scriptobject:

  Reveal hidden contents

object automaton_station
{
	void	init();
	void	station_on();
	void	station_off();

	//INTERNAL
	float	m_station_state;

	//SPAWNARGS
	float	m_time_max;		//station automatically switches off after this time if bot fails to switch it off (i.e. because it's been killed at the station). 0 = infinite.
};


void automaton_station::init()
{
	m_time_max		= getFloatKey("time_max");
}

void automaton_station::station_on()
{
	if(!m_station_state)
	{
		activateTargets(self);
		m_station_state = 1;
	}

	if(m_time_max)
	{
		sys.wait(m_time_max);
		thread station_off();	
	}
}

void automaton_station::station_off()
{
	if (m_station_state)
	{
		activateTargets(self);
		m_station_state = 0;
	}
}

 

Under the hood, I've taken the opportunity to clean up the assets a fair amount, trimming unused components and ensuring it follows TDM's conventions, which is a necessary step towards an inclusion in the core assets.

The download can be found in section D of the original post.

That's really cool Dragofer and Sotha, man I really need to play TDM more, I didn't even knew such characters existed in TDM.