Problem with cycling with multi_managers Created 6 years ago2018-06-17 12:37:37 UTC by MOCOLONI

Hi. I'm trying to create a loop/cycle between all the multi_managers I have in a map. Each one of them targets a func_tracktrain that takes 2.5 seconds to reach the end of its path, with an additional 1,5 seconds of wait until the next func_tracktrain gets targeted, making it a value of "4" seconds as the 'second target' in the multi_manager. The last target on each will fire the next one, with the last multi_manager firing the first one. However, instead of resetting the whole process, it seems that right after it apparently reaches the last target and fires the first multi_manager, it would instead only take the overall time of the whole process without doing anything, before actually getting reset.

In case the info is complex:

mutlimanagername1

• targetname1 0
• multimanagername2 4

mutlimanagername2

• targetname2 0
• multimanagername3 4

mutlimanagername3

• targetname3 0
• multimanagername4 4

mutlimanagername4

• targetname4 0
• multimanagername1 4

4+4+4+4 = 16 seconds, which is the time it takes for the cycle to get 'restarted' after multimanagername4 fires multimanagername1.

I already tried multithreading the first one, and later all of them, but nothing seems to work.

Let me know if you need the .rmf or .bsp to see what I'm talking about.

Well, a couple of things. Firstly, if the setup isn't too complex, consider compiling the four multi_managers into one:
multi_manager

• targetname1 0
• targetname2 4
• targetname3 8
• targetname4 12
• multi_manager 16

I don't actually remember if multithreaded multi_managers can target themselves, but I'm sure a trigger_relay could be thrown in if not.

Secondly, make sure that it isn't the func_tracktrains that are the problem. Try switching them out with other simpler entities to make sure that they aren't getting triggered and failing to do anything for some other reason.

Otherwise, not sure. Seems like that setup should do what you need, especially if it does actually end up looping.

Jessie said:Well, a couple of things. Firstly, if the setup isn't too complex, consider compiling the four multi_managers into one ...

Actually, there's a reason these managers aren't just one: I'm working on a map that has 60 func_tracktrains, 15 in each multi_manager and a 16th target that will fire the next multi_manager. The issue was found in that same map, so I recently made a small "test" map with only one target and one multi_manager ('the next') to see if the problem persists, which does. In the test map it's just 4 tracktrains, but the problem is still in there, as if the managers had some kind of a "Delay before resetting" (but they still use the time it takes for the whole process to end).

Right now, I'm using a trigger_once to start the process. I then used a trigger_multiple with a delay of what it takes to somehow try reactivating the first multi_manager, but it still won't work.

I'll try using a button to manually try reactivating it, and will edit this post with the result.

EDIT: Yep, there's definitely something preventing any multi_manager to be retriggered after the cycle has been completed. You can however re-trigger the first (or any multi_target in the cycle) before it completes; in my case it was the first one, but it only activated the tracktrain right after the cycle completed, like it's supposed to be the regular way.

Tracktrains may be the problem. I've already seen one person complaining that a path_track wouldn't fire its target when passed by a tracktrain. Try replacing tracktrains with usual trains, as well as path_tracks with path_corners.

Windawz said:Tracktrains may be the problem. I've already seen one person complaining that a path_track wouldn't fire its target when passed by a tracktrain. Try replacing tracktrains with usual trains, as well as path_tracks with path_corners.

I replaced Tracktrains with Trains recently, as Tracktrains seemed to be an entity for even more features that I didn't actually need; all I wanted was a moving platform that would instantly go to its initial spot after a round restart, so a func_door wasn't suitable.

Tracktrains can still fire targets by addint the target to a path_track's "Fire on dead end"; a regular Train will do the thing with "Fire On Pass".

These are no longer a problem. What I'm focusing on now is trying to make a multi_manager not get glitched on an autoloop situation.

Train entities are weird in counter-strike. Something about the way they reset isn't quite right and I can't figure it out.

MistaX88 said:Train entities are weird in counter-strike. Something about the way they reset isn't quite right and I can't figure it out.

It's not the Train/Tracktrain entities, it's the multi_managers that don't "restart" properly.

Ah, I misunderstood the details and didn't see your 2nd post.

I was always under the impression that a multi_manager loop couldn't target itself. There is an old tutorial about multi_manager looping. https://twhl.info/wiki/page/Tutorial:_Multi_manager_Looping_Made_Easy

I tried using that to loop a pattern of lights and it works but for some reason has one "fast" cycle.

I used it on my maps de_msx1 and de_msx2, but when I tried copy+pasting it over to my newest wip, it didn't work anymore (I am using Sledge now, which I didn't use for the first two maps, but I feel like that shouldn't make a difference). I then edited the sequence so the multi_manager loop would loop back on itself and it works.

I don't know why it works now. I didn't think the switch from Hammer 3.5 to Sledge would have an effect on how an entity works in game. All these maps are for CS too, so it's not like one is for a different game or mod that might be coded differently.

Edit: So many typos...

MistaX88 said:Ah, I misunderstood the details and didn't see your 2nd post.

I was always under the impression that a multi_manager loop couldn't target itself. There is an old tutorial about multi_manager looping. https://twhl.info/wiki/page/Tutorial:_Multi_manager_Looping_Made_Easy

Thank you for that tutorial, but I find it kinda complex to understand. I currently think I found a "fix" to the problem, especially for the needs in my map. If it all ends up working fine without side effects, I'll post the solution here, or at least how it works on my map since it's not a regular one.

The quick test map I threw together (now that I'm not in bed going to sleep) doesn't seem to have any problem with looping multi_managers. Nothing special going on.

If you're still having trouble, maybe post your test .rmf.

Jessie said:The quick test map I threw together (now that I'm not in bed going to sleep) doesn't seem to have any problem with looping multi_managers. Nothing special going on.

If you're still having trouble, maybe post your test .rmf.

Here it is: https://drive.google.com/open?id=1_q9jpe9medPFf6roeFQpwzWYd181Lfgs

In the .rmf you'll find a button, 4 func_trains & 2 path_tracks for each, as well as 4 related multi_managers. Each will first activate their Train, followed by the activation of the next multi_manager and etc. The last multi_manager does it all but is supposed to re-activate the first one, which it does but 4x times slower than intended.

There's also a trigger_once brush behind the info_player_start entity (it was moved Behind for testing purposes, but it's still functional [although it no longer "auto" activated upon spawning]).

When in-game, press the red button to start the cycle. Because the Trains only go up, consider dying at some point after the activation and before the fourth Train reaches its end-of-path, so all Trains will once again be on ground and you'll be able to see it takes 16 seconds to re-activate the first multi_manager instead of just 4.

However, if you press the button after respawning and before the fourth Train completes its trajectory, the first multi_manager will be re-activated in 4 seconds, as supposed.

Okay. A couple of questions/points:
Firstly, just for clarification (I don't know if it actually affects anything, but pays to know), which game is this supposed to be for? Half-Life, HL Deathmatch, Counter-Strike, etc.?
Secondly, what is the loop supposed to do? Maybe you cut it out of the file you uploaded, but retriggering those trains doesn't do anything.
Thirdly, I changed nothing but putting some func_walls in (that have toggled textures) with the same names as the trains, and compiling that shows those multi_managers looping just fine. (Testing in Half-Life.)

Y'know, just to rule out some difference in our editor/compile setups, maybe just test this out (and then compile yourself) to confirm. https://www.dropbox.com/s/sfqyxl7ubrjklt0/testmapx.zip?dl=0

I apologize if I'm not reading the issue correctly, just trying to establish exactly what it is we're trying to do

Jessie said:Firstly, just for clarification (I don't know if it actually affects anything, but pays to know), which game is this supposed to be for? Half-Life, HL Deathmatch, Counter-Strike, etc.?
Secondly, what is the loop supposed to do? Maybe you cut it out of the file you uploaded, but retriggering those trains doesn't do anything.

The map is for Counter-Strike.
The test map wasn't actually made for TWHL and was only a toned-down version of the original map, which has 60 Trains and the same way of looping the 4 multi_targets. Nothing has been cut out of the .rmf I uploaded.

As in the main/original map, the Trains are supposed to rise up and break the surface/ceiling above them (I actually think these were unnecessary for the testing as I only needed to see the Trains' progress). Since the main map has 60 Trains, with 4 minutes for the multi_managers to elevate them all, I assume the round will always restart before that happens, so all the Trains will get back to ground on new rounds. However, when the last multi_manager reaches the final target and re-activates the very first multi_manager as supposed, it takes 4 more minutes to actually do so, pretty much like in the .rmf above (although it only takes 16 seconds in there, pretty much as the regular process' timelapse).

Like I said, respawning before the last Train reaches its destination and trying to re-activate the first multi_manager with the button seems to do the last multi_manager's job just fine.

On that example map, make 4 func breakables, name them train1, train2, train3, and train4. Set them all to "trigger only".

I just did this, and what it showed that was the multi_managers keep looping. If a func_breakable is triggered again even after it already broke, it will make a sound and spawn gibs (and explode if you have that set) again. So it will go off every single time a multi_manager fires it, even if it is now a bunch of empty space.

So you are having a few problems. One problem is, like I was saying (turns out it was relevant), trains are really funky when it comes to how they "reset" on each round in CS. The other problem, is the multi_managers continually loop, and they don't reset to the start of their loop on round chance, they just keep going. So if it's currently on the second multimanager, it's gonna be rolling from the 2nd to the 3rd on the round change.

A bit more on the trains. I have a hypothesis based on what I saw on that test map that an actual player input is needed down the line somewhere to activate the trains. Maybe after the first mm loop that information is lost. Because hitting that button after a round change WILL activate the first multi_manager again and get the trains moving again, even though the func_breakables I added show the multi_managers are still looping and the trains aren't moving. So, try doing my "trigger_once_round" method to activate the loop at the start of each round (the one we talked about in that other topic) with a trigger_multiple and a game_counter.Then, make sure to stop the final multi_manager from looping back to the first. See if that reliably starts the trains on each round.

Unfortunately, since the multi_managers are on the first loop and won't stop on round change, I think you'll start getting your trains halfway down the line moving right on round start. I can't think of any way to reliably stop this, especially since you'll have no way to predict exactly where in the loop it will be when the round ends.

What about having the trains trigger trigger_relays with a delay? I can’t test this at the moment, just throwing it out there.

MistaX88 said:On that example map, make 4 func breakables, name them train1, train2, train3, and train4. Set them all to "trigger only".

I just did this, and what it showed that was the multi_managers keep looping. If a func_breakable is triggered again even after it already broke, it will make a sound and spawn gibs (and explode if you have that set) again. So it will go off every single time a multi_manager fires it, even if it is now a bunch of empty space.

I know they'll keep (randomly) breaking the already-broken breakable brushes; that's why I told Jessie in an above post to die at some point after activating the loop, so that all the Trains (except the one moving between rounds) would get on the ground, ready to be re-triggered again and see how wrong the looping goes.

Jessie said:What about having the trains trigger trigger_relays with a delay? I can’t test this at the moment, just throwing it out there.

I yet have to test that. On a QuakeWiki article it's being stated that this entity is partially useless as entities can loop each other, but I guess a trigger_relay won't hurt as looping multi_managers using themselves is actually a problem for me right now.

MOCOLONI said:

Jessie said:What about having the trains trigger trigger_relays with a delay? I can’t test this at the moment, just throwing it out there.

I yet have to test that.

Unless I'm doing something wrong, it doesn't seem to fix the problem; it still acts like it's yet another multi_manager, taking 16 seconds instead of 4 to re-activate the first one.

MOCOLONI said:I know they'll keep (randomly) breaking the already-broken breakable brushes; that's why I told Jessie in an above post to die at some point after activating the loop, so that all the Trains (except the one moving between rounds) would get on the ground, ready to be re-triggered again and see how wrong the looping goes.

No, they did not "randomly" keep breaking for me. They kept breaking on the correctly timed intervals with no extra delay at the start of the next cycle. Killing myself via console did not stop this process. 4 seconds...boom...4 seconds...boom...ad nauseam. When I respawned the cycle kept going from where ever it was just at the end of the previous round. The round end does not stop multi_managers. The one thing it did not keep triggering is the trains, like you said, except hitting the button would get them going again, and all the trains that had reset would function just one more time in the loop. If I timed it right my func_breakables actually showed two independent loops going through the same multi_manager loop.

This goes back to what I said before, the problem has to do with the func_trains. The well timed intervals of my added func_breakables are clear evidence that the multi_manager loop is functioning perfectly. Yes, the trains that are supposed to be getting triggered by said loop seem to stop working, but the func_breakable's with the same names as the trains are proof that the multi_managers are indeed firing those targets. Now, it's very possible that you'll have to modify how the whole loop works because of how the trains are behaving. It won't be because the old loop wasn't working; it will be because func_trains are janky in CS and for some reason will only get triggered by a perfectly working loop on it's first cycle.

MistaX88 said:Now, it's very possible that you'll have to modify how the whole loop works because of how the trains are behaving. It won't be because the old loop wasn't working; it will be because func_trains are janky in CS and for some reason will only get triggered by a perfectly working loop on it's first cycle.

Would rolling back to func_tracktrains help at something, if at all? I know Trains and Tracktrains are different entities but I just need either as a counterpart to Source's func_movelinear entity.

It's not a func_door right now and it's never going to be due to it not going back to its spot instantly (it's just "closes/opens" at the round start, which is something I want to prevent players from seeing).

MOCOLONI said:

MistaX88 said:Now, it's very possible that you'll have to modify how the whole loop works because of how the trains are behaving. It won't be because the old loop wasn't working; it will be because func_trains are janky in CS and for some reason will only get triggered by a perfectly working loop on it's first cycle.

Would rolling back to func_tracktrains help at something, if at all? I know Trains and Tracktrains are different entities but I just need either as a counterpart to Source's func_movelinear entity.

Yep, rolling back to the entities I initially used seems to have fixed the whole issue. multi_managers actually restart the cycle just fine, and there are no side-effects unlike when using regular Train entities (such as dying during a Train's trajectory will immediately teleport that Train to its destination on the next round, without firing targets specified on its final path_track).

Not sure if that's what you meant by "Trains have a weird function in CS" as you didn't state whether it was for func_trains or func_tracktrains.

Anyway, thank you all for the info provided!

I just meant "trains" in general because I haven't really used tracktrain and wasn't sure if it had the same quirks (though, I also thought they were only good for something with train controls). I'm honestly still not sure exactly what the issue is with func_train in CS but your setup has given me some insight into something I might test out in the future IF I decided to experiment with func_train (specifically, the fact that they seemed to work fine on the first loop of a multi_manager loop, but not afterward, unless you pushed the button, in which case, they would work once on that new loop).

Either way, I was just trying to make the point that the func_breakables functioned as a sort of "test lead" to see that the multi_manager loop itself was working as intended. Glad you finally sorted the problem out.