multi_manager Last edited 4 months ago2024-07-23 00:27:43 UTC

multi_manager - Point Entity

The multi_manager entity can activate several different events (including itself) at specific times. It can only be used when the SmartEdit option in the multi_manager's properties is disabled. To add targets, click "Add" and enter the name of the target entity in the "Key" text box, and a delay of activation in seconds as the "Value", then click OK.

Attributes

Name (targetname) - Property used to identify entities. You need this in order to activate the multi_manager.

Flags

Multithreaded (1) - Allow the multi_manager to be called multiple times concurrently. If not set the entity will ignore being used until it is done calling all its targets. See notes below.

Notes

Naming: When naming a multi_manager, do not call it "multi_manager", as the entity will not function properly. Make sure to give it a name that relates to your entity setup, e.g. "explosion_mm".

Order: The keyvalues list are placed in the order that they were created in, instead of when they get activated first. This means that reading what a specific multi_manager does is messy, because it's not clearly visible what entity gets activated first. Keep that in mind when trying to edit already existing `multi_manager`s.

Entry limits: Be aware that a multi_manager can only have a maximum of 16 individual targets, in the order of entry as aforementioned. If you add more than that, then the rest will simply not activate. If you need to activate more than 16, then you should use more than one multi_manager and activate all of them at once to get the timings more easily.

Multithreading: Normally, if the multi_manager is called again before it has finished its work-order, it will ignore the new call and will just carry on with its work. However, with the Multithreaded flag enabled, each call spawns a clone of itself which starts firing the targets, and removes itself after all targets have been fired. This solves various problems, mainly related to multiplayer games (where you might want a multi_manager to start up for each player that joins - if one player joins while the multi_manager is still going for another player, a new thread needs to be created). Be aware that a new copy of this entity will be created every time it is triggered. If the map is near the entity limit, after a number of copies are created the limit will be reached and the game will crash. If you're getting unexpected/unexplained crashes, this might be a reason.
Having a multi_manager call itself only once as its last target is relatively safe to do in single-player, provided the multi_manager is externally activated only once. The calling clone removes itself, having finished its task list, as the new clone is spun up, which means there are at most 2 clone entities at any moment.

Repeat target calls: You can call the same entity multiple times in a single multi_manager by appending a number sign (#) and a number or letter to the entity name. e.g. having the following keys and values will toggle the entity foo three times:
- "foo#0" "0.001"
- "foo#1" "1"
- "foo#2" "2"

Looping: Since it's dangerous to have multithreaded multi_manager entities call themselves at the risk of out of control cloning, it is more prudent to have an external timer setup call a multi_manager that's not multithreaded. An external timer also means you can easily pause, resume, or kill the timer without interrupting the multi_manager if it's currently running.

A multi_manager saves and relays the activator reference. Use it instead of trigger_relay if you want to have a delayed trigger that's also passing the activator reference along.

6 Comments

Captain Terror

Commented 16 years ago2008-05-28 02:43:39 UTC Comment #101112

Multi_managers and looping note:

If your using an MM as a continuous loop (by having the MM call itself at the end of it's routine), it will only loop if you have the "multithreaded" flag checked!

Captain Terror

Commented 15 years ago2009-02-24 09:41:18 UTC Comment #101113

"Maximum of 16 individual targets. "

More like 8, to keep it safe. Check out this thread for more info! = )

Stojke

Commented 12 years ago2012-03-14 20:31:33 UTC Comment #101114

Pay attention to the "Game crash" warning as it is the usual case of map crashes when using this technique.

Also don't forget to make the start time 0.1 and not 0, as 0 can cause the map to crash and/or other game bugs.
That said, when deactivating something, lets say:

00laser1 0.1
00laser1#1 2.1
00laser1#2 ??

Do NOT start it after it is deactivated (00laser1#2 2.1), give it 0.1 seconds freeze time (or more if you need it):

00laser1 0.1
00laser1#1 2.1
00laser1#2 2.2

And remember not to use long entity names, for example (i use):

0lsrmm (Laser control multi manager)
0expmm (Explosion control multi manager)

User#6970

Commented 7 years ago2017-11-22 23:31:59 UTC Comment #101115

Proper looping:

Proper looping is done with an env_beam repeatedly shooting through a func_button with health = 1. info_targets must sandwich the button. The button activates the multi.

The env_beam must have damage set to >=1. Change Strike again time to set the loop frequency.

Note: You'll lose the activator (current player) reference.

Linda420303

Commented 9 months ago2024-02-01 20:16:02 UTC Comment #105948

multi_manager supports triggerstates, by default its use-type is "Toggle".
Add a "#x" at the end of the value, where "x" is the triggerstate value:

"0.001#0" means to trigger via use-type Off after 0.001s
"0.001#1" means to trigger via use-type On after 0.001s
"0.001#2" means to trigger via "killtarget" triggerstate after 0.001s

multi_manager is basically a trigger_relay now with this knowledge!

Admer456

Commented 9 months ago2024-02-02 01:53:19 UTC Comment #105949

I think that's Sven Co-op-specific, isn't it?
opens up the code
Yeah, there's nothing in HL SDK that points to the parsing of #N there. It is always USE_TOGGLE. Either way though, good to know!

You must log in to post a comment. You can login or register a new account.