Certain entities/functions not resetting their conditions. Created 6 years ago2018-06-08 17:47:58 UTC by MOCOLONI

Hello. First of all I'd like to add that I'm relatively "new" to mapping for the GoldSrc Engine games. By new I mean I actually made (or 'have been making') a few maps for Counter-Strike, but unlike my 6-year mapping experience in Source games, I know nothing but the basics in GoldSrc, so perhaps this thread's point is already a thing to many people that know far more than I do.

It seems that entities like trigger_once seem not to get restarted after a round restart. They work fine once used, but not anymore until the map as a whole is reloaded. A multi_manager won't also stop firing all its targets and instead will keep doing so until reaching the last one.

Is this a known bug/feature? If at all, are there any 'proper' workarounds than just using other entities (and sometimes lots of other stuff) just to replicate the broken ones' function?

I know very little about the way rounds work in CS entity-speaking. However, what is it you don't understand about multi manager? I didn't get what your problem is.

Loulimi said:I know very little about the way rounds work in CS entity-speaking. However, what is it you don't understand about multi manager? I didn't get what your problem is.

The multi_manager entity was just an example. If you know how Source mapping works, let's suppose that its counterpart, the logic_relay entity, fires targets with some delays; a round restart would also reset the logic_relay, but in GoldSrc/multi_manager's case, it doesn't happen and everything continues with the job until finishing.

In case you're still not sure what I'm talking about: a trigger_once is supposed to be used once, but not 'forever' like it does in the GoldSrc engine - in the Source one, the entity can be used again once the round restarts, while in GoldSrc it doesn't.

I understand what you mean. As far as I know, doors tend to close every time a new round starts, and they also have a "Fire on close" key. So in theory, if used with the "Toggle" flag enabled and "Delay before close" set to "-1" (And maybe also with "Start opened" flag enabled as well, not sure), you can trigger entities whenever a new round starts.

I've just tried to construct an entity setup that involves this func_door trick. What it's supposed to do is to disable a trigger_multiple when a player touches it, and then enable the trigger when a new round starts. I tried disabling the trigger itself with a multisource set as its master, also I used a trigger_auto to enable the multisource on map start but the multisource seems to stay disabled for some reason. Not sure if it's even possible. But it's most likely my fault as I've never been good at setting entities up.

However, if you somehow manage to find a workaround, feel free to share it.

Also, since you're new to goldsrc mapping, I suggest you to read through all or most of the tutorials if you haven't already. This could help you alot.

If you're mapping for CS, forget everything you know about Source entities. Unfortunately, there are severe limitations. Goldsrc doesn't have the input/output system of Source and not many entities reset from round to round. It's just something you have to work around.

func_door is your friend.

func_door resets every round. So, if you want to trigger something on round start, use a hidden func_door. It can just be a little null textured cube in an unreachable room somewhere on the map. All you have to do is set the target of the func_door to whatever entity you want triggered on round start. Use a multi_manager if you need multiple things to happen. I have a complex system of multi_managers and trigger_changetarget entities to create this round setup on my latest map. https://twhl.info/vault/view/6279 (note that the func_door in this map also needed a name so that each trigger_changetarget could change it's target to the next rounds multimanager). When using multi_manager, NEVER use the multithreaded option. Your map will crash in no-time if you do this. If what you are trying to do requires it to be multithreaded then what you are trying to do is a bad idea in a CS map (it doesn't necessarily mean your intended result is a bad idea, it just means, in Goldsrc CS, it's not happening).

I can't remember every entity that resets off the top of my head so you'll have to play with them. Most of them don't have a target so func_door is the most reliable round start trigger. func_breakable always resets, so whatever gets broken will come back each round. func_train is really quirky in cs, it doesn't seem to fully reset, it keeps doing it's thing but jumps back to it's first stop target at the start of each round (I used a constantly running func_train to periodically trigger a bird sound near CT spawn in my map de_hollis, but because of this weird quirk, and because I have the sound triggered on the first stop target, the sound always plays at the start of the round).

trigger_once only works once per map, and never again. trigger_auto fires on map load and that's it. I've never had to do this, but you could tie a trigger multiple to a game_counter, set the initial value to 0, set the limit value to 1 (this means it will fire it's target when it hits 1). Afterwards, the trigger multiple will keep triggering the counter but it already hit it's limit and won't fire again. Then have a hidden func_door trigger a game_counter_set that resets the counter to 0 on round start. That way, you could have a trigger that can only fire once per round. I've never had to do this, so hopefully there aren't any unknown quirks that will get in your way, but it's worth a shot.

The setup would be as follows:

Put your trigger_multiple that you only want to fire once per round wherever you want it to be. You can use whatever names you want, these are example names. Set it's target as "oneoff" and delay before reset to 1. Create a game_counter, set it's name to "oneoff" and set it's target to whatever you want to target (I'll just call it, "thing" for this example). Set the initial value to 0 and set the limit value to 1. Create a game_counter_set, set it's name to "oneoffset", set it's target to "oneoff", and set the new value to 0. Then finally, create a hidden func_door (can just be a random cube hidden somewhere) and set it's target to "oneoffset".

Edit: I just remembered another big one, light entities reset to their initial state on each round. You can't target anything with them but it's important to know if you're making any setups using switchable lights.

MistaX88 said:If you're mapping for CS, forget everything you know about Source entities. Unfortunately, there are severe limitations. Goldsrc doesn't have the input/output system of Source and not many entities reset from round to round. It's just something you have to work around.

func_door is your friend.

func_door resets every round. ...

Appreciate your reply a lot, especially for letting me know that a multithreaded multi_manager can cause problems.

I should've added some more note such as that I've mapped "enough" in GoldSrc at this point to be aware most things you posted, but it's still a welcome reply as I would probably have never used a Door specifically to fire targets (although I discovered so by accident almost a year ago, but I'm certain I would not've kept that in mind).

In fact my upcoming map for a community uses breakable brushes and tracktrains guided by 4 multi_managers (the idea is using them to reach the Breakables and break them, as there isn't a logic_case counterpart [or is there one?]), and got to know that both these entities get restored on round restart. I also got to know that it only fires the last 16 targets (or basically 'just 16 targets') - I thought ticking the "multithreaded" flag would fix it, but nothing seemed to change (except a bigger filesize and longer compile times), but didn't experience any crashes (I guess it only happens on multiplayer servers).

@MistaX88

The workaround you've described doesn't seem to work. When activated, game_counter increments 1 to its initial value, 0, but since the limit is also set to 1, the game_counter resets back to 0 so the trigger can be used over and over again.

EDIT: Nevermind, I had the "Reset on fire" flag checked by default. Sorry for the inconvenience.

That's good to know though. It could be default on the OP's setup. It isn't on mine. So, add to my little example, make sure "reset on fire" is NOT checked on the game_counter.

Also I wonder why my example didn't work. The multisource seems to stay disabled, no matter if it's activated on start with a trigger_auto or with a trigger_once positioned at where the players spawn. I clearly remember that I could set a multisource as a master for a trigger_multiple and it would work.

Still tho, your example is much cleaner than my entity setup. I'll be using it instead in case I need to.

Oh, and I missed the fact that the OP posted.

You might still run into weird quirks with the func_trains. Make sure you test all sorts of likely and unlikely situations on the map (especially, last player dying during the cycle, after the cycle, before the cycle, etc).

What happens when you select "multithreaded" is it allows the multimanager to be triggered again even when it's still in it's cycle (so a new cycle would start behind the old cycle and the old would still continue). Without it checked, it simply ignores inputs while it's in it's cycle. The problem is, multithreaded does this in a really hacky way, by just creating a copy of the same multimanager whenever it gets triggered while still in it's cycle. These extra multimanagers are not temporary. So, the longer the map is played, the closer those duplicated multimanagers reach the engines entity limit. Someone let me know if I got a detail wrong here, I'm pulling this from memory alone right now.

EDIT: I've created an example map utilizing 2 different setups that use game_counter and game_counter_set, as well as a standard trigger_once and trigger_multiple setup just as a side-by-side comparison of their inadequacy. It sounds like you guys already get the concept but I'm sticking it here for anyone else that might stumble over this topic in the future.

Kinda unrelated, but would giving a different entity type the name of another entity allow the multi_manager actually fire more than 16 targets? I mean, let's suppose one of the targets is called "target1", and it's a func_door brush entity - would a func_breakable of the same name break at the same time the func_door is being triggered?

There's just one new thing I'd like to get done, and my multi_manager entities all need their current 16 targets to be fired. I could perhaps create a sub-entity that does the new, extra job and Then fires one of the multi_managers, but I think that's both a dirty and unnecessary workaround.

MOCOLONI said:In fact my upcoming map for a community uses breakable brushes and tracktrains guided by 4 multi_managers (the idea is using them to reach the Breakables and break them, as there isn't a logic_case counterpart [or is there one?]), and got to know that both these entities get restored on round restart. I also got to know that it only fires the last 16 targets (or basically 'just 16 targets') ...

You can give a func_door and func_breakable the same name if they both will be triggered simultaneously.

Alternatively, it wouldn't be that difficult to replace one of the 16 entities in a multi_manager with another multi_manager, and then have that new multi_manager trigger the other entity. You can have a branching tree of multi_managers.

MistaX88 said:Alternatively, it wouldn't be that difficult to replace one of the 16 entities in a multi_manager with another multi_manager, and then have that new multi_manager trigger the other entity. You can have a branching tree of multi_managers.

That's what I referred to with "creating a sub-multimanager", but instead of the 16th target being a multimanager, I thought of sub- one being the first, firing the "extra" target and then the multi_manager full of targets.