Tutorial: Multi_manager Looping Made Easy Last edited 2 months ago2019-04-22 09:14:34 UTC by Penguinboy Penguinboy

Download attachment

Looping a certain set of events may be a tricky move to master, and most known ways to do this are by using multi managers that contact each other to complete these looping functions. But as we know, to successfully loop a set of multi managers, you will need to enable its "multithreaded" flag in the flag options. By doing this your map is on an immanent course of crashing itself.

This tutorial will show you a few tricks you can use, and in what conditions. Also it will point you to some things you will need to pay attention to to make your loops function as correctly as possible.

I. First things first, what are "Multi managers"?

Multi managers are entities in Half Life engine (Gold Source) games that when called/requested call upon other entities you placed in the multi manager. By doing this you are able to activate a set of entities at once, or control their behaviour in a looping sequence.

Multi managers can activate/deactivate/set any type of entity that can be controlled this way. Here is an example picture of what a multi manager entity does:
Graphical example of multi manager functionGraphical example of multi manager function
An other entity requests/calls a multi manager, after which the multi manager starts to call upon entities you have set into the multi manager. These entities can be Sprites/Sounds/Other point - solid entities. More info about multi manager and how do they work can be found here:

multi_manager
Tutorial: Multi_manager

II. Information on this technique

What we know

As some of you may know, looping a certain set of events can be done by using multi managers. For example, two multi managers will contact each other at the end of the sequence list you've made and loop a certain set of entities. But, for this we need to enable the "Multi-Threaded" flag, which will cause problems over time, depending on complexity of the loop and the number of entities in the map.

As you know, multi managers will ignore any request call until they are finished with the sequence they are going trough. So in order to make them work the way we want to we need to enable the multi threaded flag. This causes the multi manager to create a copy of it self, and the entities used in the loop sequence, after which it starts to loop again with out problems. BUT, doing this, the multi manager will continue to copy it self over and over until the total amount of entities goes over the 512 engine limit and the map crashes.
We do not want our maps to crash.

What should we do

To prevent crashing, we must use some kind of a way to loop our multi managers with out them bugging out.
The trick is to contact an other entity which will than contact the starting multi manager and start the loop all over. Here is an example picture of how does it work:
Looping explanation diagramLooping explanation diagram
As you see on the image, all we do is ask the multi manager No: 1 to start all over. As you can see, in this set up, after a set number of requests multi manager No: 1 is finished, and asks multi manager No: 2 to start its cycle, which than contacts other multi managers in the set up to finish their cycle.
When the final multi manager is finished it calls upon an entity which reactivates the first multi manager.

This was an example, of course, in case you used them to make a set of events, activate sprites and trigger hurts at a sequenced interval for example.
As you know the maximum number of targets in an multi manager is 16, but its best to keep it safe and use maximum of 8 targets per multi manager (at once).

III. Looping it right

Note #1: Its all about timing
Note #2: I don't know of a way can multi manager loops be stopped each round, for needs in counter strike, i am still working around that, maybe some one will find a way after reading this tutorial.

Types of loops:

1. Timed loop -> Normal setup that finished after all multi managers in the sequence are done

Not much is to be said here, just normal linking of multi managers which do not loop after they are done

2. Always loop -> Begin ON map start or trigger - loop till the map is finished

What is essential for this one is the triggering mechanism. Knowing what i said in part II, I have constructed mine out of Env_beam and func_button. What i did is take advantage of env_beam's Start ON flag and Func_buttons shootable function.

What we do here is place our button in the path of the Env_beam, which will than damage the Func_button and cause it to activate:
Target/button position in VHETarget/button position in VHE
What we need to set is:

env_beam
Object propertiesObject properties
Object flagsObject flags
We set "Toggle" so we can start it again once its done and "Start on" so the loop begins on map start

func_button
Object propertiesObject properties
Object flagsObject flags
We set "Do not move" so it doesn't move out of position

Once we have set the triggers we will make sure it loops properly. Set the final multi manager in the looping sequence to target the Env_beam entity. Once it targets the Env_beam entity it will activate and trigger the Func_button entity which will start the loop from 0 once more. This will assure your looping will be complete every time.

Note: You can also activate it with an button if you wish, you can use the same Env_beam set up and target it with a button, or you can just use jsut the button and target that button with an other button. It should loop with out problems.

IV. Summary

Multi managers can be linked in a long line and they need to be let to finish their original sequence. Dont forget to check the map example for more information.

There should be no problems with using this type of technique and it should not bug as long as you pay attention to timing and setting the whole ting up right. You can probably combine to achieve other ways of looping or getting what you want,.

Remember to pay attention to multi manager limits and entity names. Do not make loops too complex. Keep it as simple as possible, and work out the sequence on paper first.
Remember to check all the values and in case of sprites and sounds, check how long they are and build your time list accordingly.

Do not rush.

V. Additional information

You can see in the file archive how I made my sprites loop, with a bit of bugs thou, but nothing a little editing cant fix.

What id like to do here is write how i plan my loops. Since they can not be controlled fully (as far as i know), aka can not be stopped each round, i always use this only when i want to make something that will always loop.

First thing before we start planning, we need to know what desired effect do we want to achieve and we need to know some information about the sprites and sounds we use.

Some sprites are looped and you can hardly notice when do they start and when do they end, such sprite is, for example, "fire.spr". Others do not loop like that and you can clearly see when they are starting and when they are ending, example of such sprite is "blast.spr".
When it comes to sprites that are looped and we cant notice much difference between start and end, we don't have to worry about the time value we will use. But, when it comes to sprites that are clearly noticeable we need to calculate and set a time value for realism.

When we take a look at the blast.spr sprite file with out handy sprite explorer we can see that it has a total 13 frames from beginning to end. This means, by using the default 10 frames per second value in Env_sprite entity, it will take 1.3 seconds for this sprite to complete its cycle. When making our entity set up we must take this value into count, because we want it to look as realistic as possible, we cant have our sprite ending too early. So, when setting up our time line we will take these 1.3 seconds into count.

Second, sounds. Some sounds are looped, some aren't. Most atmospheric sounds are, and ending them at any time usually isn't noticeable. Here its really about sync-in the sound and sprite time value.

Once we know what are we dealing with, and that we prepared everything, we need to plan out our sequence. I will demonstrate a simple sequence of sprite and sound:

Lets say we have a machine that bursts steam and a steam sound.
We will call the spots where steam appears A and B.
I have decided this to be the pattern:

A B
1 0
0 1
1 1
0 1

Where we have 1, steam and sound will play, where we have 0 nothing will happen.

So, I named them:

Sound1
Sprite1
Sound2
Sprite2
Mmanager1
Mmanager2

And I have planned them to fire for 2 seconds, and wait for 1.5 seconds:

Mmanager1

Sound1 0.1 //Starting value of 0.1 so we avoid bugs
Sprite1 0.1
Sound1#1 2.1 //Ending after 2 seconds of being activated
Sprite#1 2.1
WAIT //1.5 seconds wait time
Sprite2 3.6
Sound2 3.6
Sprite2#1 5.6
Sound2#1 5.6
WAIT
Sound1#2 8.1
Sprite1#2 8.1
Sound2#2 8.1
Sprite2#2 8.1
GO TO //Since we reached the maximum for one multi manager, we go to 2nd one
Mmanager2 10 //Call manager 2 after which manager 1 finished its function

Mmanager2

Sound1 0.1 // We continue in manager 2, since we waited 2 seconds to call manager 2, we can start this ones functions at 0.1 again
Sprite1 0.1
Sound2 0.1
Sprite2 0.1
Sprite2#1 1.6
Sound2#1 1.6
Sprite2#2 3.6
Sound2#2 3.6
GO TO // Managers did their purpose, time to call them again
Activator // Activates manager 1

Conclusion

That was an example of how to plan everything out and input it correctly.
Times will usually be in pattern, making your job easier, so just stay focused and work it out all with understanding and don't rush.

Hope this helped, and happy mapping!

10 Comments

Commented 7 years ago2012-04-01 21:11:22 UTC Comment #101051
Great stuff! I've yet to only read through it, but when I eventually get the itch to map again, I will definetly take notes from this tutorial.

Regarding to reset each round for CS. If you can trigger it to reset or start through spawns; where everyone spawns outside the map in some box which triggers the multi_manager, then gets teleported to their original spawn points.
That's at least what I do to trigger stuff each round.

Source: http://twhl.info/forums.php?thread=17380
Commented 7 years ago2012-04-02 06:57:10 UTC Comment #101052
awesome stuff sir! if i was stuck on a desert island with a pc, i could spend the rest of my days working on complex enitity setups and be happy ;)

food for thought: maybe you guys ought to include a copy of the tutorial(in pdf or html or whatev) with the download, so we can archive it neatly/completely in our "tutorials" folder ;)
Commented 7 years ago2012-04-02 06:59:37 UTC Comment #101053
p.s. i love your graphic font what is it? =)
Commented 7 years ago2012-04-02 14:46:05 UTC Comment #101054
@ Xzec

Hmm... Since a second entity controls the whole thing, maybe a way to stop it on each round... I know it can be timed... I will have to think about this one, or if our genius Captain Terror thinks of something :P

@ Captain T

Thanks! Haha, id make sand castles xD
Also i agree we should make a PDF out of tutorials, that would be nice. Big Book of Mapping, remember that? :D

Also, the font is Nice Sega Sonic Font:
http://dl.dropbox.com/u/54462712/stuff/NiseSegaSonic.TTF
Commented 7 years ago2012-04-03 13:18:05 UTC Comment #101055
@ Stojke:
Yeah, I didn't manage to make it work. Though what I tried to do was:
1.) Put info_player_start inside trigger_multiple brush.
2.) The trigger_multiple targets func_button* with info_player_start as master.
3.) A trigger_teleport around the info_player_start targeted to info_teleport_destination.

But without any luck.
  • Tried the first multi_manager aswell.
Commented 7 years ago2012-04-05 16:04:17 UTC Comment #101056
thanks sir! i was guessing return of the jedi and i'd never have guessed sega! =)

(and of course, i too would make some sand castles);)
Commented 7 years ago2012-04-10 14:23:16 UTC Comment #101057
Maybe is the whole loop was controlled by a well timed env_beam... So once i want it stopped i just trigger its toggle function...

Have to test!

Also no problem T man, just ask :P
Commented 4 years ago2014-12-06 20:19:03 UTC Comment #101058
The setup with the env_beam didn't work for me, so I used an env_laser in the end. The 2nd multi_manager triggers two times the env_laser to switch it on and off to trigger the func_button which triggers the first multi_manager again.

an env_explosion works too triggering the button, but you always hear the explosionsound.

The "trigger-rythm" is much cleaner that way imo.
Commented 3 years ago2016-01-02 19:57:33 UTC Comment #101059
I've been having trouble making a MM of mine loop without using the flag option. I will try this and see what comes of it.
Commented 3 years ago2016-01-02 21:02:39 UTC Comment #101060
Didn't work for me either. I will try what Dr Turbografix has offered instead.

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