Targetname/Target "Setter", kind of inverse lmd_terminal
Sorry for the weird title, couldn't think of how to describe it in few words. Well, this is what I think would be useful:
Nonsolid or Solid ent, has 6 targetnames, and 6 targets. If targetname1 is fired, the ent will fire target1 when used. It targetname2 is fired, it fires target2 when used, etc. When it would fire it's target would be determined by spawnflags -
1 - nonsolid, fire when player enters bounding box
2 - nonsolid, fire when player enters bounding box and presses "use"
3 - nonsolid, fire on console command
4 - solid, fire on use
5 - solid, fire on console command
Or something along those lines. The main reason I think this would be useful is for teleports - you set the teleport somewhere, and it teleports players there until set otherwise. It's doable with multiple teleports and target activates/deactivates, or a tele, gates, and activates/deactivates, but this would save a lot of ents in such cases.
- Login to post comments
The multiple-targetnames concept was considered by Robo, but I don't know if he started messing with it yet.
Still, nice idea.
like a gate with 6 channels.
ofc depending on what you want to do with it, more than 6 things would be nice too.
I have needed this ent in the past, and just worked around it as you said.
So how is this different than 6 individual relays/triggers?
people are lazy phred, you must learn to accept this
You would only need 1 relay then, AND, if you use a terminal to handle toggle you will only need 1 targeting entity.
EX:
Teleporting from point O1 to {S1 or S2 or S3 or S4 or S5 or S6}
+lmd_terminal ->
-target1 -> (target_Activate -> S1) + (target_Deactivate ->5 (S2 + S3 + S4 + S5 + S6))
-target2 -> (target_Activate -> S2) + (target_Deactivate ->5 (S1 + S3 + S4 + S5 + S6))
-target3 -> (target_Activate -> S3) + (target_Deactivate ->5 (S1 + S2 + S4 + S5 + S6))
-target4 -> (target_Activate -> S4) + (target_Deactivate ->5 (S1 + S2 + S3 + S5 + S6))
-target5 -> (target_Activate -> S5) + (target_Deactivate ->5 (S1 + S2 + S3 + S4 + S6))
-target6 -> (target_Activate -> S6) + (target_Deactivate ->5 (S1 + S2 + S3 + S4 + S5))
+trigger_multiple ->
-target1 -> target_relay -> ( S1 + S2 + S3 + S4 + S5 + S6 )
Entity count:
1 terminal + 6 activate + 6 deactivate + 6 targetables + 1 targeting + 1 relay
Total 21 entities. In this case 9 non logic,and with the entity SnipEye wanted it would reduce to 10 entities.
Conclusion:
Entity will not bring new functionality, just save a lot of typing. And if it just supported 6 states I would probably not use it. Entity would be better superseded by a scripting system.
In order to deactivate 2, 3, 4, 5, and 6 at the same time, they would all need to have the same targetname.
Actually target_(de)activate can handle target, target2, taget3, target4, target5 , target6 ...
-WEAPON_X
| Status: | Pending | » | Will not add |
I am not going to redesign the entity system to support this, the variable system should solve this whenever I get around to it. There is no server entity count hit for using any of the needed ents anymore, including trigger_multiple. Also, it is redundant as its easy to make this with standard logic entities. Thats 3 against, and the only thing it has going for it is "lazyness". Will not add.
- Login to post comments
In reality, it's not different from placing an lmd_terminal with 6 targets, placing 6 ents that can all target, and placing activates/deactivates to choose which one you want active. However, ents required to do that is:
6 activates,
6 deactivates,
6 relays,
6 targeting ents (trigger_multiple,etc)
so 24 ents total, maybe you could eliminate a couple if you used other, tricky ents, but it's still a ridiculous amounts of ents for a relatively simple system. Some servers (like tidal) sell houses, and placing 24 ents to have a cool teleporter in a house might break the ent budget that's allowed for a house. Hypothetically, of course.