[MODDING BUG] func_trackautochange crash

[KyuuGryphon]

Not really sure if this is the right place for this… Anyways.

I started experimenting with BM’s first OaR map (bm_c2a2a) to get a feel for how mapping in non-L4D Source games works, and to that end, added a loop around the tracks similar to .RK’s Loop Mod.
At some point, while working on the level, I set the branch path to default to the path I added, which formed a closed loop around the level. The “main” path (that would take the player to the bridge to the next level) became the alternate path. This was for the sake of ease while testing, so I wouldn’t have to manually fire the path_track to use the alternate path every single time.

With the loop set as the primary path, Black Mesa would crash the moment that the func_trackautochange elevator at the beginning of the level reached the bottom floor - I was eventually able to track (pun fully intended) the source of the issue back to me having turned the tram path into a closed loop. Reverting it to how it was before (wherein the primary path is the one that takes the player to bm_c2a2b) fixed the crash.

This isn’t something that causes problems in the regular game, of course, and I wouldn’t know whether or not this is a limitation of how the entity is set up, but I thought it might be worth reporting anyways…

[RK1]

It’s funny you should bring this up, because I encountered the exact same thing while making Loop Mod. It’s been a while since I looked at this particular entity but I’m sure that the simple setup (that you could see on Uncut’s A1 map) worked there, but for some reason doesn’t work in the A map. It have to do with dropping the tram on this new path (via the elevator). I don’t know.

For reference:
OaR - Loop Mod

[KyuuGryphon]

I haven’t looked at Text’s A1 map, so I dunno what he did to circumvent the issue, but I managed to fix it by just having a trigger enable the alternate path near the beginning of the level. I’m not sure why that works, while having the loop built into the track doesn’t, but… well, it does work, so I’m not complaining.

Getting kind of off-topic here, but - On that note, reading the post you linked to, I see that we’ve ended up running into the same problem with Source’s brushface limits. If you don’t mind my asking, how’d you get around that? When Hammer started squawking at me about the brush limit, I ended up getting around it by removing the elevator at the end of the map (which actually works out better for what I’m thinking of doing for the rest of the chapter) and turning all the “sidewalks” alongside the rails into props, which is… less than ideal, as the lighting gets screwed up and the texture alignment ends up being all wrong.

For what it’s worth, when I took to Google to see what the brushface issue was about, I found this article on the Valve Dev Wiki, which clarifies that the compiler’s brush limit includes the bounding boxes for any non-cubic or angled brush… which, in On A Rail’s case, means every corner, the sidewalks, the bevelled ceiling, the detailing on the walls… and so on. :fffuuu:

[RK1]

Concerning the brushsides limits, the thing that I did the most was simply geometry. And when I say geometry, I actually mean under the hood. When working with the A map at least, I noticed that a lot of the structures contained within were made out of more brushes than they needed to be.

With the A map in particular though, the electrical box in that sealed off room is a shitload of brushes. And the downed pipe near the electrical pool puzzle also utilizes a lot of brushes. I made the former into a prop and un-downed the latter.

It’s a huge pain to deal with and even now I haven’t fully escaped it myself. Unfortunately it’s a hardcoded limit so the only thing you can do is have less brushes.

I am under the impression that Source 2007 SDK was a lot nicer when counting brushsides, because I noticed I started having difficulties again when I switched to the more recent SDK that ships with BM. That might be worth looking into, I think. Not sure what effect it has on compiling, but it’s probably not a problem. Probably.

[KyuuGryphon]

Bumping this back up because reasons - I have another map that I’ve started working on, with a similar loop as what I added to c2a2a. I tried setting up the track so that the default path is the loop, and the alternate path is how to continue forward - like with c2a2a, when the elevator to this section arrives at the bottom of the shaft, the game crashes.

So whatever the issue is, it definitely seems to be related to a series of path_track’s that either have no endpoint or link back to themselves somehow.