What determines entity transitions?

Does anyone know what criteria the Source engine uses to determine which entities will be transferred from one level to the next during a transition? I’ve set up an elevator transition (as in bm_c1a1e) from c1a2b to c1a2c: when I use it c1a2c becomes filled with physics props and npcs from b, with no readily apparent factor determining what is transitioned and what is not (other than that most of the objects taken were “nearby”). The Valve developer wiki seems pretty poorly documented on this issue- it describes in general terms how to make a transition, but that’s about it.

You can use trigger_transition for that. IIRC the game tries to do is based off of PVS or line of sight or something, but adding a trigger_transition over the area visible from the info_landmark will ensure everything in it is carried over.

Great question. Here’s my answer:

I DON’T BLOODY !@#$% KNOW! >.<

I’ve been trying to figure this out for ages. It seems almost completely random. I do know that physics props, decals, and NPCs are guaranteed to make the transition. I also know that dynamic props SOMETIMES make the transition. Brush entities will never transition. prop_door_rotating also makes the transition sometimes, although I have no idea when or why.

Also, the “Global Entity Name” field seems to break everything for some inexplicable reason.

DAMMIT VLAVE

Current findings:

  • Trigger_transitions are RELATIVELY good at ensuring physics props will make it through a transition (have yet to test with other types of entity, but since most other types aren’t very portable I doubt that is a big deal).
  • Preventinga specific set of entities (or everything but a set of entities) from transitioning is more difficult.

[list][*]Pure point entities do not appear to transition.

  • Brush entities do not seem to transition.
  • Both doors (and other dynamic-like entities with non-mobile models?) and physics objects seem to correlate transitioning with PVS visibility. Thus, I am going to be looking at manipulating the PVS system- seeing if occluders, areaportala, and other objects that at least in theory prevent visibility can also prevent transitioning.
    [/*:m][/list:u]
  • If a trigger_transition entity is bound to the transition, any entities not within its volume will not transition to the new map.

UPDATE: It seems that neither areaportals nor occluders can stop entities from transitioning. Will try to alter visleaves directly- if this does not work I will have to implement the extremely hackish solution of teleporting the player into a different elevator up above the map (or something). However, a very similar elevator transition at the end of Unforeseen Consequences works perfectly.

I carry the hat through the complete game and even if u drop the hat and u move forward (knowing u see the place where the hat is dropped again), u find the hat again, even after saving game, level transitions,…

So I wonder how they did this aswell!

That’s normal. Source does that pretty much automatically.

At this point, I’ve pretty much thrown up my hands in despair and created an elaborate system of identical elevator cars and trigger_teleports to accomplish the necessary transition in Office Complex. It seems that the engine is very aggressive in transitioning entities, and making it not do so is something it has a lot of trouble with.

How large is your transition trigger?

The actual trigger_changelevel is just a little block in a corner of the elevator, controlled by way of the button and the Changelevel input. There is no trigger_transition, as in addition to anything in the elevator a lot of entities outside of it would transition automatically. Adding a trigger-transition over the elevator volume did not help with this.

Perhaps I’m not understanding something. Why is it necessary for you to transition anything other than what’s in the elevator?

Well, that’s exactly my point. I don’t want to transition anything but the contents of the elevator. The problem is that a large number of props (as well as a few NPCs and doors) outside of the elevator are also transitioning, and I am completely unable to stop them from doing so.

What’s the name of your trigger_transition?

Currently there is none, as I have removed it. Previously, it was named identically to the info_landmark the elevator used.

If it was named identically, then anything outside the trigger should not have transitioned. Also, this sounds very suspicious, because a level change WITHOUT a transition trigger should have simply failed and not worked at all in the first place.

Are you sure that’s the only transition trigger?

Confirmed there are no trigger_transition entities extant on the map. There are multiple trigger_changelevel entities, of course. I had a trigger_transition in the elevator previously, but it did not have the intended effect of preventing everything outside of the elevator from transitioning. Given your information, I can only conclude that I missed something then- will retry.

That appears to have done it. I’m not sure what was wrong before (the new trigger_transition is as far as I can tell an exact duplicate), but it seems that in disproof of my previous statement, trigger_transitions also prevent any entity outside of its volume from transitioning.

Necroposting to add an important caveat in case anyone looks to this for reference: the trigger_transition must be present in both maps in order to prevent pseudorandom entity transitioning. I’ve just discovered that if it exists in one map but not the other (or has a different name, of course), it will not demonstrate the above behavior and will instead transition based on the wiggy PVS behavior previously outlined.

Its only Necroposting if the thread in question has been inactive for a period longer than roughly 7 months. Nevertheless, this is good information to have.

I only consider it necroposting if it’s dropped off the first page AND you respond to the conversation with no new information as if people hadn’t stopped talking about it.

Since you have new information to add, I think you’re fine.

Founded in 2004, Leakfree.org became one of the first online communities dedicated to Valve’s Source engine development. It is more famously known for the formation of Black Mesa: Source under the 'Leakfree Modification Team' handle in September 2004.