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

Lpfreaky90 wrote:
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

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?

Quote:
func_instance_IO_proxy with the correct output onproxyrelay

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.

FelipeRRM wrote:
What I still don't understand is the advantage os instances over prefabs... instances seem much more complicated!

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.

I like the fact that you will only need to rename the prefix in order for it work perfectly in-game. By creating a prefab of an instance you can have automatically named instances with the _&i option.

I work a lot with instances (mosifications of the stock instances) and as Lp said they have the big advantage that any change you introduce into them will be shown in every map you use them. That's why I hardly collapse them in any map except when I have to tweak them a bit to fit some of their settings into a certain place in a map.

The most interesting part to me is to mess around with the inside inputs/outputs and then target them to be fired by the func_instance_io_proxy. I think this is an awesomely useful system.

Well, could you help me again?
A map created on PTI has both elevator as instances, and they use that teleport entity. Well, I need to move that entity a little, if I collapse the instance, and move the entity, will it mess up everything?

FelipeRRM wrote:
Well, could you help me again?
A map created on PTI has both elevator as instances, and they use that teleport entity. Well, I need to move that entity a little

I'm not sure about why would you need to move tha entity a bit. Anyway, if you're referring for example to that entity that teleports the player to the elevator right in the beeginning of each map so the player can start moving altogether with it, that entity is a point_teleport and you have it right at the bottom of the elevator prop into the instance elevator_arrival_logic:

FelipeRRM wrote:
if I collapse the instance, and move the entity, will it mess up everything?

You don't really need to collapse it, simply edit the instance, move that entity and save it under a different name for example. Anyway, I don't think you mess up everything if you collapse it though. But I'm not sure which names will hammer give each entity inside these after collapsing, check that out carefully because the arrival_elevator_logic and the elevator_entrance instances work along firing i/o from one to the other.

No no, I need to move the point_teleport that teleports the player into that little room which says the number of the level right before entering on the puzzle area. It's because I've added another room, and I need to put it between the elevator and the main level itself...

FelipeRRM wrote:
No no, I need to move the point_teleport that teleports the player into that little room which says the number of the level right before entering on the puzzle area. It's because I've added another room, and I need to put it between the elevator and the main level itself...

Just move the room with the level number back and add the room between that room and the map and you should be fine.

But unfortunately it must be between the elevator and the level number room, can't be after level number room. I'll try to figure out something here, may'be i'll create a instance of my own. Can you use like 3 instances, save it as a map and use it as single instance? Maybe this will help me a little.

Then you need to go into the instances, remove the world portals and doors and link them together with normal doors manually...