Refering to a specific type of entity instead of targetname only [CLOSED]

M

Mark "Banda`MF" Ward

Hello guys. I'm having a problem, that I couldn't find any proper solution to. I have a prop, that's being attached to a player while he is spawning, that is getting the same name as !activator(player name). Is there any way to specify entity type when I'm trying to kill that prop, because if I'll refer to a prop by targetname only it will remove a player, not a prop.
 

Izotope

Sourcerer
aa
May 13, 2013
698
764
Yes you can target an entity class instead of its targetname, in your case probably prop_dynamic.
 
M

Mark "Banda`MF" Ward

Yes you can target an entity class instead of its targetname, in your case probably prop_dynamic.
Could you please explain in better details how I should filter entity by prop_dynamic class? I've been trying to make this system in a lot of different ways, including AddOutput, but I think I'm missing something really basic in here, because it feels like there is a much simpler way of implementing this... Sorry for playing dumb, but this is my first time working with VHE at all. :<
 

Tumby

aa
May 12, 2013
1,084
1,192
While making an output, you can target every prop_dynamic by simply typing "prop_dynamic". However, this might be too much considering you want to only have a specific prop_dynamic removed.
There is also the class filter (Filter_activator_class) which will filter for all entities of the given type (again, "prop_dynamic"). Not to be confused with Filter_tf_class which is for TF2 player classes.
You will need to have another filter for names (Filter_activator_name) and then one or more Filter_multi to "add" these filters together. Don't forget you can specify another filter_multi inside a filter_multi.
Then you will need to somehow get a reference to a specific prop_dynamic by using these filters and probably a trigger or such so that you can use !activator to target it.

Would be much easier if you can somehow keep the targetnames seperate instead of copying them.

Or maybe you can add an output to each prop_dynamic by using the AddOutput call? (Or maybe just have it in there from the start.) Giving each prop_dynamic an "OnUser1 !self kill" would mean that you can then send the "(YourEventHere) (name of prop and player) FireUser1" input and bam, prop's gone.
 
M

Mark "Banda`MF" Ward

While making an output, you can target every prop_dynamic by simply typing "prop_dynamic". However, this might be too much considering you want to only have a specific prop_dynamic removed.
There is also the class filter (Filter_activator_class) which will filter for all entities of the given type (again, "prop_dynamic"). Not to be confused with Filter_tf_class which is for TF2 player classes.
You will need to have another filter for names (Filter_activator_name) and then one or more Filter_multi to "add" these filters together. Don't forget you can specify another filter_multi inside a filter_multi.
Then you will need to somehow get a reference to a specific prop_dynamic by using these filters and probably a trigger or such so that you can use !activator to target it.

Would be much easier if you can somehow keep the targetnames seperate instead of copying them.

Or maybe you can add an output to each prop_dynamic by using the AddOutput call? (Or maybe just have it in there from the start.) Giving each prop_dynamic an "OnUser1 !self kill" would mean that you can then send the "(YourEventHere) (name of prop and player) FireUser1" input and bam, prop's gone.
The only reason why I'm naming a prop as an !activator, is because I couldn't figure out a way of performing a string concatenation for !activator and something else, like !activator_prop. I'll try doing this step by step according to your answer, thanks for your help :)
 
M

Mark "Banda`MF" Ward

Nope. Doesn`t work. I still cant pass "!activator" value from func_button, called game_playerdie to filter_activator_name`s "filtername" value.
 

Tumby

aa
May 12, 2013
1,084
1,192
Honestly you can ignore the first part of what I said. I was just trying to keep the idea of calling the prop_dynamics separetly, but it's super hard to actually get working.
The much easier method is just the small bit I stuck at the end.
Or maybe you can add an output to each prop_dynamic by using the AddOutput call? (Or maybe just have it in there from the start.) Giving each prop_dynamic an "OnUser1 !self kill" would mean that you can then send the "(YourEventHere) (name of prop and player) FireUser1" input and bam, prop's gone.
 
M

Mark "Banda`MF" Ward

Honestly you can ignore the first part of what I said. I was just trying to keep the idea of calling the prop_dynamics separetly, but it's super hard to actually get working.
The much easier method is just the small bit I stuck at the end.
In my case, that doesn`t work aswell. I dont know how to pass !activator value from entity with targetname "game_playerdie", according to official documentation I`m doing everything in a right way, but it still doesnt work, even in this simplified "OnUser1 -> FireUser1" scenario.
EDIT1: I just tried with trigger_brush, and, still, this thing doesn't work either.
 

Attachments

  • main_test.vmf
    55.5 KB · Views: 151
Last edited by a moderator:

Tumby

aa
May 12, 2013
1,084
1,192
I see what the big problems are.

1. You are giving the briefcase the targetname of the player.
The problem here is that players dont have targetnames. Do not confuse targetnames with the ingame name of a player, you can't access those anyways. You would need to give each player a unique targetname first, which requires a very complex setup.

2. You are using !activator to call an entity that isn't the "activator".
When using !activator, only the entity that has started the current I/O chain will be called. You can not use this to call an outside entity that happens to have the same name as the !activator.

Bonus: You can't actually press your button.
In order to make functinal buttons in TF2, you need to either use the "OnDamaged" output OR go into the flags and check "DamageActivates".

Considering I don't know what the big plan is with your setup, I can't really help yet. You will need a different setup depending on the prop being able to spawn again, having more than one at a time, different teams being able to access it or each having their own or only one team, removing it when the player dies or leaves the game, areas that force it to be removed (for example the spawn to prevent people changing class and causing all kinds of weird stuff to happen) etc...
 
M

Mark "Banda`MF" Ward

I see what the big problems are.

1. You are giving the briefcase the targetname of the player.
The problem here is that players dont have targetnames. Do not confuse targetnames with the ingame name of a player, you can't access those anyways. You would need to give each player a unique targetname first, which requires a very complex setup.

2. You are using !activator to call an entity that isn't the "activator".
When using !activator, only the entity that has started the current I/O chain will be called. You can not use this to call an outside entity that happens to have the same name as the !activator.

Bonus: You can't actually press your button.
In order to make functinal buttons in TF2, you need to either use the "OnDamaged" output OR go into the flags and check "DamageActivates".

Considering I don't know what the big plan is with your setup, I can't really help yet. You will need a different setup depending on the prop being able to spawn again, having more than one at a time, different teams being able to access it or each having their own or only one team, removing it when the player dies or leaves the game, areas that force it to be removed (for example the spawn to prevent people changing class and causing all kinds of weird stuff to happen) etc...
Main idea was that if player is getting killed, then a prop is getting killed aswell. About that button... I'm using game_playerdie as a trigger event of a player dying and passing his name as activator (try compiling the map and see for yourself, that button is actually getting triggered by players death). I didn't knew, tho, that you have to name players first, so I'll be working on that system aswell. Again, thanks for pointing out those mistakes of mine.