Quote from MrTwoVideoCards on May 13, 2011, 2:14 am

I think you should be able to drop it in, and then specify the next level in the landmark entity. If you need to edit the instance though you could collapse it. I don't really know though, I haven't implemented any level changes yet, but I'm pretty sure thats how it works. I think they have a trigger at the bottom of the elevator shaft that fades out an env_fade, then just loads the next map. They don't have to worry about transitioning to the next levels exact geometry like in Hl2 for example, so it should be pretty straightforward.

Quote from msleeper on May 13, 2011, 2:26 am

It looks like there is an instance called "instances/transitions/arrival_departure_transition_ents.vmf" that handles all of it - level loading and map ending/fading, and it assumes you have elevators - but it has a lot of static stuff like some end-map text that I haven't figured out how to change yet. I'm really trying to avoid collapsing instances if at all possible, since it looks like Valve never had to. At least not in their example maps.

Quote from msleeper on May 13, 2011, 4:29 am

Okay so far it looks like all you need to do to get functioning elevators with transitions is to place these 5 instances in your map:

Code: Select all

instances/turbine_elevator/arrival_elevator_(your choice)_base.vmf
instances/turbine_elevator/arrival_elevator_logic.vmf

instances/turbine_elevator/departure_elevator_(your choice)_base.vmf
instances/turbine_elevator/departure_elevator_logic.vmf

instances/turbine_elevator/transitions/arrival_departure_transition_ents.vmf

The arrival and departure "base" instances have a few options, be sure you use the correct set. The "a4" are the Wheatley ones, so the elevator goes upwards in those and the elevator room isn't destroyed. If you are looking for the 1940's Aperture ones, they are in "tube_elevator" and they work just the same. You want the two actual instance entities to be in the same location, the "base" and "logic" instances are built to overlap on each other.

The arrival_departure_transition_ents.vmf is what handles the meat of getting these to actually work. You must have this instance in your map if you are using one or both instance elevators. There are individual instaces for the arrival and the departure, but I don't think they are supposed to be used independently.

There are some quirks, though. Your Portalgun upgrade and the end map text is all handled outside of the entities in a vscript. It kind of sucks. Right now I'm trying to make my own version of the arrival_departure_transition_ents.vmf instance to handle this on my own, but I think ideally it would be best to use a custom vscript so you don't have to fuck with the instances.

Quote from Sidneys1 on May 13, 2011, 6:25 am

^That should be on the VDC.

Quote from msleeper on May 13, 2011, 6:25 am

As soon as I can lay down some more mad science on how this shit works, I'm probably going to put it up there.

EDIT
Example/test/hilarious map I made messing around with this. Use this as an example on how to do transitions with the stock instances.

Good Enough For Science (Instance Example + VMF)

Quote from msleeper on May 14, 2011, 5:33 am

So me and Cassata were playing around with some more Instances tonight. I used the Gel instance because it requires direct I/O interaction to use - whereas the ones I used previously didn't really require anything beyond plopping them into a map.

There are a couple of article on the VDC about instances (one, two) the second of which is written with L4D2 in mind but the concepts stay the same. Sadly there does not appear to be a ton of information about Instances, so I'm hoping to be able to expand on that once I myself have a more firm grasp of things.

Anyway, what you need to know in this example is that you can rename or "Replace" certain fields in an instance from within your map VMF. Within your instances, anything that is given a value that begins with a $ symbol grants the ability to be Replaced. The example that is given in the articles I linked is using $color in an instance, to allow your map to alter the color of an object. In the case of the Gel spawners, there are two Replacement fields - $trigger_to_start and $trigger_to_stop. In this particular case, these correspond to the names of two separate logic_relays, one that turns on the gel flow and another that turns of off.

It's important to know how sub-entities within an instance are renamed, when it is required that they are named. Part of this is handled in the func_instance in your map itself. Since our two logic_relays in our instance are named Replace-able fields (since they start with a $ symbol), giving them a name allows our map to interact with the logic entities within the actual instance.

That said, you need to understand how the renaming behavior works before you can actually target these logic entities from any I/O Outputs. The option "Entity Name Fix Up", which is at default to "Prefix", controls this behavior. Using the default "Prefix", and assuming you have given the entity it's own unique name in the "Fix Up Name" (which, for all intents and purposes, is the targetname of the instance), the new name of any entity within an instance is renamed to: (value of your map's func_instance "Fix Up Name")-(name of the entity in the instance)

It gets more complicated when, in this Paint example, we actually Replace the name of the logic_relays. So instead of the name of the entity, the name of the logic_relays is whatever we set in the Replace fields in the func_instance.

So, assuming we named the instance "test" and we Replaced $trigger_to_start to "start" and Replaced $trigger_to_stop to "stop", the name of the logic_relays that controls the starting and stopping will be called: test-start and test-stop

Still with me? Good. At this point, it's just a matter of very basic logic I/O. I setup a switch that sends a ToggleTest to a logic_case, which then either triggers test-start or test-stop during the OnTrue or OnFalse Outputs respectively. Keep in mind that, because the entities are not technically in your map in Hammer, the I/O links will appear red. This is fine, things should work properly in-game.

I know this is kind of insane to read and it's like 5:30am so I'm sure I wrote this pretty retarded and over complex. But here it is, and here's the example, and I'll be happy to help anyone with questions.

Gel Spawner - Instance Example + VMF

Quote from p0rtalplayer on May 14, 2011, 11:39 am

On a related note, the way valve does it is they have the outputs set up like so:

OnWhatever | Instance_fixupname | instance:entitywithin;input

It's more complicated and I have no idea why they'd do that over the way msleeper explained but I just thought I'd mention it.

Quote from Supervillain on May 14, 2011, 12:41 pm

ahh! This is awesome work. Should give me something to chew on for the weekend.

Quote from msleeper on May 14, 2011, 4:04 pm

p0rtalplayer - I think it actually depends on what the instance is doing. Take a look at the first VMF I posted and the button there does that. I think the fact that the logic_relays are Replace'd is what means you have to do it this way. More testing required.