Advantage of Info_Teleport_Destination

[EmNudge]

After a small bug that I fixed, I found that a trigger_teleport's remote destination can be almost any entity!

This can let me Place filter_multi's, a light_environment, logic_auto's around my map in conjunction with the trigger_teleport. All this does is remove the need for Info_Teleport_Destination entities.

So, is there any problem with my "method"? Does the main entity make anything easier or better that my way would mess up?

 

[Phil25]

I don't know the technical stuff but the former does give you a representation of the player model dimensions, which I myself found helpful a couple of times.

 

[EmNudge]

I don't know the technical stuff but the former does give you a representation of the player model dimensions, which I myself found helpful a couple of times.

Yes, of course, but can't you just use one to make sure you have enough space and then switch it for something else afterward?\

I always do things, paranoid of the entity count. This lets for you to use one less entity per trigger_teleport, which, in maps with tons of those, saves a lot of entities.

 

[Phil25]

I very rarely have any entity at the position I want to teleport the player to but I understand your point. But in such small improvement, I think it all comes down to preference in the end.

If you have an entity nearby which doesn't do anything based on its position then sure you can move it, but I wouldn't relocate those entities if they were further away because you'd usually put them where they fit, a logic_branch near double doors, for one.

Another reason is because this entity is made only for that purpose, and there is a chance (please don't take my word for the following) that the Source engine does some optimizations based on it. However, the wiki does recommend info_target over info_teleport_destination, which is the entity specifically designed for acting as a target.

It would be neat if you could point the teleport at info_null, which gets removed when the map spawns. I haven't tested it, but I doubt it will work.

 

[EmNudge]

I very rarely have any entity at the position I want to teleport the player to but I understand your point. But in such small improvement, I think it all comes down to preference in the end.

If you have an entity nearby which doesn't do anything based on its position then sure you can move it, but I wouldn't relocate those entities if they were further away because you'd usually put them where they fit, a logic_branch near double doors, for one.

Another reason is because this entity is made only for that purpose, and there is a chance (please don't take my word for the following) that the Source engine does some optimizations based on it. However, the wiki does recommend info_target over info_teleport_destination, which is the entity specifically designed for acting as a target.

It would be neat if you could point the teleport at info_null, which gets removed when the map spawns. I haven't tested it, but I doubt it will work.

I tested it and, as you thought, using an info_null as a remote destination will not work.
ALTHOUGH, I had a different theory which worked very well!

Triggers have origins. In many cases (like leak checking), the origin is considered the entity, not the brush. THEREFORE:
When using another trigger as a remote destination you are sending the player to its origin, not the brush. Since you can target yourself, a trigger_teleport can send a player to itself, which is actually its origin!

We have just found a solution to removing that one entity! We can just send the origin halfway across the map and teleport the player to itself!



The main problem is that using an origin as an entity can be pretty annoying, especially when trying to find it. Another problem is accidentally selecting the entire map and centering the origins for bug testing. That'll reset our origin to its original spot.