Ticket to Ride

Smart ideas to leverage the func_train_mp entity

Ticket to Ride Hexen II Edition

Even those of you not familiar with the famous Ticket to Ride board game should guess after the picture I'll talk about trains. Trains are certainly the most versatile brush entities in Hexen II. With a bit of imagination and tweaking, a trigger entity + a train can more or less emulate any kind of brush entity: breakable_brush, func_angletrigger, func_button, func_door, func_door_rotating, func_rotating, func_wall, etc. A true Swiss Army knife!

It became all the more true when Portal of Praevus turned the classic func_train into the even more handy and powerful func_train_mp! So it's really an entity that is worth spending time studying in detail. There is so much to say that I won't try to cover the whole topic here. I'll take for granted that you know already the "basic" functionalities (not so basic in fact) and focus on some ways of using it which somewhat go over the classic uses.

Station stops

A cool innovation brought by func_train_mp compared to its predecessor is the new value -3 supported by the wait property. It makes the train wait each time its reaches a path_corner. When the train is triggered again, it resumes its journey to the next path_corner, and so on as many times as you want. It's not just a back-and-forth travel between two points, but can be a full itinerary with many stops. Works in conjunction with spawnflags value 2, and also depends on how the path_corners themselves are set up (they have their own wait property). A few tries may be necessary for you to achieve your goal depending on what you want.

Use origin

"Use origin" is the label associated to the spawnflags value 64. A life changing enhancement! With original trains you had to bother with the min point of the train, that is the corner of its enclosing volume with the minimum x, y and z. And everything was revolving around it: where the train spawned at map start, how it moved to its path_corners... Annoying!
Now thanks to "Use origin" the train's origin is not that awkward dumb min point anymore but any point YOU decide by giving the train a custom origin with an origin brush (that is a small cubic brush with the special ORIGIN texture on it, whose center defines the train's origin). Far more easy to fine tune the train's moves.

Funny variations

As said in the introduction, lots of brush entities can be replaced by a train. That means you can make funny varieties of those entities by taking advantage of the more complex moves a train can perform:

• Pseudo-breakable_brush thrown in the air and swirling before exploding
• Pseudo-func_angletrigger rotating back and forth
• Pseudo-func_door_secret not stuck anymore to the usual 2 right angles moves
• Pseudo-platform with a corkscrew movement (spinning as it goes up)
• Etc.

3D models as trains!

Like what you've read this far? Just appetizers. Now the really cool things begin...
The weaponmodel property is the real game changer. Its applications are so many! It turns the train from a classic brush entity into a 3D model like those in TrenchBroom's Entity Browser: artefacts, items, torchs, monsters, barrels, chests, plants, etc. Now any such 3D model can become a train! Put the path + name of the .mdl file where the model is stored in the weaponmodel property and you're done: the train's brushes become invisible (but keep on being solid to represent the volume occupied by the model, which is non solid) and the 3D model appears where the train should be, positioned at the train's origin (specified by a mandatory origin brush).

Portal of Praevus has many examples: the left and right parts of the big opening Buddha statue in tibet3 - The False Temple are 3D models, so are the darn prayer wheels in tibet4 - Courtyards of Tsok or the cauldron in the secret lab hidden somewhere in keep3 - The Duke's Keep where the most ridiculous transmutation ever takes place (put a dragon tongue in a pot of soup and you'll get a piece of jewelry! We French people know a bit about cooking and fashion, and believe me it never worked!).

Good news: all mdl models can become trains! With models having several animation frames managed programmatically like monsters you cannot choose the frame and the model won't animate either (unless you go deep into HexenC code modifications), so monsters are obviously a poor choice unless a static "monster statue" makes you happy. On the other hand, anything static by design or with an automatic internal animation (like spinning items or waving flag) works.
And you are even not limited to the entities displayed in the TrenchBroom's Entity Browser: all mdl models found in the PAK files are available: weapons, projectiles, puzzle pieces...
And of course you can use your own custom mdl files as well.

Before we go more into detail about the applications in the next sections, a small caveat: if your train moves involves rotations, only its invisible brushes will rotate by default (which won't be very spectacular for sure!). If you want the 3D model to rotate accordingly, check the train's spawnflags value 32 (Angle match).

New objects

"Official" entities (those listed in the Entity Browser) are declared in HexenC code and have a dedicated spawn function to precache the model. But when the func_train_mp entity has a weaponmodel, it does the precaching job automatically. So you don't have to code anything at all, even if it's a custom model the game never ever heard of. As long as its complexity stays within the game engine limitations, it's supported. Very good news!

It's a nice way to widen the variety of objects the player can see in your maps and to create new atmospheres. A func_train_mp doesn't need to move if you just want to display a new kind of static plant or statue or whatever. It doesn't have to be a train. The func_train_mp is then just a host entity for your mdl model thanks to its precaching mechanism. In such case, don't even bother with a path_corner and give your func_train_mp the same target and targetname: it will spawn at the very point you placed it in TrenchBroom.

Indestructible objects

We all know the Hexen series has lots of secrets behind breakable_brush entities, so players use to destroy everything they can (sometimes just for fun!). Well, The problem for me is that in one of the maps in Wheel Of Karma: A Tulku Odyssey, statues are involved in a pretty sophisticated puzzle. Having them destoyed would simply ruin the puzzle.
Guess what? I don't need actual statues! Indestructible entities looking like statues (because they use the same 3D model) do the job. Trains are not actual statues so they don't suffer their destructible nature. They cannot be broken by the player (they can explode but only if instructed to do so through configuration). They can even make moving statues if I want! What more could I ask for?

Moving puzzle pieces

Let’s remember a short clip from a movie which dates us a bit (but we are all fans of a game from 1997 after all, right? So I know I’m targeting the right age group!).

Can you guess what movie it's taken from?

Doesn't that short scene evoke a puzzle piece put at the right place where it has to be placed? Let's forget the "place" in question is a scary cyborg self-placing the puzzle piece in its own chest and that embarrassing greedy moves made by the pincers, and let's focus on how we could adapt this sequence in our favorite game. That could be something like this:

1. As the player gets close to the puzzle piece destination place, a small hatch opens and a small cart comes out to receive the piece.
2. If the player has the required piece, it disappears from the inventory and pops on the cart the usual way.
3. The cart goes back inside the wall taking the puzzle piece with, then the hatch closes (and probably a door opens nearby or whatever and the quest goes on).

Impossible with a classic puzzle_static_piece entity (its name tells it already: it's static).
But nothing impossible anymore if the popping piece is a train (not actually popping up but travelling to the right place so fast, say at a speed of 999999, that practically it "teleports" there). Certainly not suitable for any kind of piece, and needs some careful timing and everything, but definitely doable. And most impressive to your players, for sure!

Safe spawning puzzle pieces

About the previous trick, to be 100% fair I should have mentioned that unlike a puzzle_static_piece, a puzzle_piece can move if pushed by a brush entity. tibet5 - Temple of Kalachakra shows an example once the Wheel of Time puzzle has been completed by pushing the Jewel of Buddha out of the wall with a sort of paddle wheel. Yet if a puzzle_piece is spawned to play the role of a puzzle_static_piece, although the player won't see the difference because they share the same 3D model, please take into consideration that the puzzle_piece is susceptible of being picked up once again by the player. That would be too weird and a way of preventing that must be thought of. Whereby if you are allergic to public transportation you have a very decent alternative to trains.

Yet puzzle_piece poses another problem: it is extremely sensitive to the space available and will not spawn if it does not have enough space to do so. For that reason a faithful remake of the video above would probably not work with a puzzle_piece: the piece would have to spawn between the too narrow pinchers and would refuse to do so.

But enough with that exercise, and let's focus on the information I just spilled... and what it implies: when the required space is not available, a puzzle_piece never spawns. It's not a problem when the piece is present right from the beginning and spawns along with all other entities at map start, as long as you placed it in a cleared area. But on some occasions puzzles are designed in such ways that the puzzle_piece is initially not there and only appears when the required actions are performed. It is the case in demo1 - Blackmarsh with the Bones of Loric and the Mithril Transmutation. Now what if at the very moment the piece is about to pop into existence a monster is too close to the spawning spot? The piece never shows. So it's never picked up and without the piece the corresponding puzzle(s) will never be solved and the game has become unfinishable. The player might restart from a save made before the corruption occurred, but since nothing showed their is no clue something wrong happened and most probably the player will go on exploring, override their save with corrupted ones, spend hours wondering where the f*** missing puzzle piece is and eventually give up, full of anger against you mapper.
The risk is real and definitely has to be taken into account. By chance it can be easily avoided thanks to a careful map design... or a train!

If you want to have your puzzle_piece spawn in an area where there is no such thing as zero risk about a monster passing by, there is nothing wrong with your map; you just have to make a train with the desired 3D model spawn there (actually moving there at super speed) instead of a real puzzle_piece. Trains dont care about monsters and geometry: they go through everything without complaining. Around the "spawning" spot, an initially deactivated trigger_once activates at the same time and when the player touches it the train goes away instantly and the actual puzzle_piece is added to the inventory thanks to Auto get.
Auto get is a little known (if not unknown) feature corresponding to puzzle_piece's spawnflags value 4. It adds the puzzle piece to the player inventory without needing the player to actually pick it up or even see it. And that's exactly what we need to complete the trick! Hide the actual puzzle_piece close enough to the train's "spawning" spot (maybe just under the floor where monsters can't go). The player must be less than 200 units away from it at the moment they touch the trigger_once otherwise Auto get won't work. You now have a safe & operational spawning puzzle piece, with even the regular flashing screen and "You possess the whatever" message.