Instances: how do they really work?
Hello there guys! I just wanted some information on how to work with instances, I've searched a bit but couldn't find any comprehensive guides on them.
Like, I've seen some very strange inputs/outputs on them, with '@' at the beggining, what does that do?
Another thing, when placing a elevator entrace on my map, I must use a arrival_departure_transition_ents.vmf, and it already has a info_player_start, but when the game starts, the player is already in the elevator, which is in a completely different position to where the player_start is, how did he apper there, without any connections between the instances?
Basically, it copies and pastes into the map.
"@" at the beginning means global - even if it's in an instance, anything can access it.
Teleporters. No, seriously. Look at the hardcoded example ones.
But how does the teleporter know where it's destination is, if I did not add any outputs to it?
theres a point teleport in the elevator. it has the same model as a prop_portal.
the name's global, so only one is allowed per map.
Yeah usually if you have something in an instance it's kinda hard to access it.
For example: I have a relay called relay_do_something in my instance.
If I want to access it from outside the instance I need to:
* Give the instance a name. (instance)
* Make sure the instance has a func_instance_IO_proxy with the correct output onproxyrelay.
* Create an output: Instance:relay_do_something;Trigger.
If you add a @-prefix to it it's a lot easier:
* make sure the @relay_do_something is in the instance.
* Let something trigger @relay_do_something, trigger.
The problem however is that this is the case for ALL @relay_do_something things. So if you have two separate instances with the same @relay_do_somethings they both will trigger.
(This is the problem with multiple cube dropper instances in a map (the old instances not the pti ones))
So I made a one portal instance once, and I had:
open_blue_relay
@close_blue_relay.
open_orange_relay,
@close_orange_relay
This way I had control over which portal got closed while I could close any blue or orange portal no matter where with the same input.
Hope that helped 
For example: I have a relay called relay_do_something in my instance.
If I want to access it from outside the instance I need to:
* Give the instance a name. (instance)
* Make sure the instance has a func_instance_IO_proxy with the correct output onproxyrelay.
* Create an output: Instance:relay_do_something;Trigger.
If you add a @-prefix to it it's a lot easier:
* make sure the @relay_do_something is in the instance.
* Let something trigger @relay_do_something, trigger.
The problem however is that this is the case for ALL @relay_do_something things. So if you have two separate instances with the same @relay_do_somethings they both will trigger.
(This is the problem with multiple cube dropper instances in a map (the old instances not the pti ones))
So I made a one portal instance once, and I had:
open_blue_relay
@close_blue_relay.
open_orange_relay,
@close_orange_relay
This way I had control over which portal got closed while I could close any blue or orange portal no matter where with the same input.
Hope that helped
Thanks mate, things are a little bit clearer now!
But even though, I still don't understand how one instance (which has the player spawn) is interacting with the elevator, because I didn't even connect them together with inputs/outputs!
and what is this entity's job?
instances are vmfs, they are uncompiled maps
when the map compiles they get collapsed into your map as if they were not instances
durring the collapsing process to avoid entity names from interfeering with others, everything in an instance gets either a prefix, or a post fix... default prefix
so inside your instance you have a entity called kill_the_player... and your instance name is called theKILLER
now your kill_the_player entity will be renamed in the bsp as theKILLER-kill_the_player
this is the reason you shouldn't name your instances the same... because then you will get identical entity names and then you'll have a whole slew of problems (most likely)
if an entity has the @ at the beginning of its name, then that entity will keep its name durring the collapsing process
this can be used if you want instances to communicate with other instances more easily
instance communication used to be broken, so they were very important. but now you can use inputs and outputs with the func_instance_proxy
What I still don't understand is the advantage os instances over prefabs... instances seem much more complicated!
The biggest advantage is that when you change a prefab, its copies don't change. When you change an instance, they do, since instances are read at compile-time. An instance also acts as a single entity, with inputs and outputs and keyvalues, so there's that flexibility too.
The biggest advantage is that every change your make is automatically in all your maps.
For example if you make an instance for a fizzler and you want to do make a change to it for example to add a laser field to it. If you do this is automatically added in all maps.