This page will discuss the organization systems and tools we will use to make content for Trakpak3.

The File System

Because it is expected that Trakpak3 will contain an enormous amount of models, materials, lua, etc., I've had to re-think my previous organization system.

Models

Track

When generating track using John Henry, the E2 will take care of most of this for you.

Track will be organized by gauge, signified by a short identifier such as "rsg" for standard gauge, "2ft" for 2-foot narrow gauge, etc. This identifier should be unique, and will be appended onto the end of "modes/trakpak3_" for a folder name. Thus standard gauge track goes in the models/trakpak3_rsg folder, and 2-foot goes in the models/trakpak3_2ft folder.

The identifier should describe what makes this group of track unique. It is possible to have two sets of track that are different in some way - for example, a 2-foot track pack with ballast and a 2-foot track pack without ballast (and 3D ties in place of it). The identifier should be different for each group, so you could have "trakpak3_2ft" for the ballasted pack, and "trakpak3_2ft_noballast" for the non-ballasted pack, for example.

Within the individual gauge folder, track should be further organized by piece type. These should be:

• straights for straights
• arcs for arc curves
• banked for banked arc curves
• bends for parallel Bezier curves (End Direction == Start Direction)
• dynamics for non-parallel Bezier Curves (End Direction =/= Start Direction)
• switches for switches
• spl for special track.

Straights don't require any further organization past this point, as the model name should be encoded with the rest of the information needed to describe the piece.

Arcs and Banked Arcs are organized by curve radius. A 2048-radius curve goes in the r2048 folder, and so on. Beyond that, the model name is encoded similar to the straight pieces.

Bezier curves (bends and dynamics) require no further subcategorization. The model name is encoded with the rest of the information needed.

Switches are then categorized into the following subfolders: turnouts for straight/arc, sidings for straight/bend, xover for straight/bend crossovers, wyes for symmetrical arc/arc, str_bez for straight/dynamic, arc_arc for asymmetrical arc/arc, arc_bez and bez_arc for miscellaneous arc/bezier and bezier/arc, and bez_bez for miscellanous bezier/bezier. The model name is encoded with the rest of the info needed.

Special track can have any level of organization deemed necessary, since there is no standardized system for it.

Everything Else

Non-track models are organized by the nation they are for. As with track, a short identifier should be used, appended to the folder name. So for example, a US-style station platform model would go in models/trakpak3_us, and a British-style platform walkover would go in models/trakpak3_uk, and a Japanese-style crossing gate would go in models/trakpak3_japan, etc. If a country's folder name has been used already, try to coordinate your folder name to match it.

Models that can be used by many nations should go in the models/trakpak3_common folder.

From there, most models would fall into several common categories, such as signals, switch stands, roads, stations, etc.

Materials and Textures

There is an important difference between the two. Textures are the .VTF image files that get used and referenced by Materials, which are .VMT text files. Multiple materials can use the same texture, thus the same texture can be used on both brushes and models, if you have a separate material file for each. Most models in Trakpak3 are made in Hammer with Propper, so this sharing happens quite a lot.

Textures and Materials are grouped first according to whether they are for use on a model or on a brush. Secondly, they are organized by national applicability. ALL TEXTURES (regardless of whether they're for brushes or models) should go in materials/trakpak3_xyz, for example. Brush materials are also stored this way. MODEL MATERIALS are kept in materials/models/trakpak3_xyz, for example.

This can all be confusing, so here's an example to illustrate what I mean.

Suppose you're making a stop sign model in Hammer. It needs two textures, one for the pole and one for the bright red stop sign face. Let's say those textures are materials/trakpak3_common/metal/metal_silver.vtf and materials/trakpak3_us/signage/stopsign.vtf. You need to have one material for each (materials/trakpak3_common/metal/metal_silver.vmt and materials/trakpak3_us/signage/stopsign.vmt), and these materials reference the two VTFs internally.

So you make the model and compile it, and now the model needs materials. The easy way to do this is to copy the material files (NOT the texture files) into whatever folder the model uses ($cdmaterials in the .QC file) and change the shader. So let's say the model uses models/trakpak3_us/signage as its material folder. You'd copy the material files over to get materials/models/trakpak3_common/signage/metal_silver.vmt and materials/models/trakpak3_us/signage/stopsign.vmt. If you use multiple $cdmaterials lines, the model will accept any materials that match the required names in any of the $cdmaterials directories.

Note: Propper by default will automatically convert materials for you. However if your textures have any kind of material proxies in them (used for animated textures and color-forcing in gmod), they will break because Propper lowercases the whole file. It's better to either delete these material files or tell Propper not to compile them at all by using the "-nomaterials" parameter in the command line.

In order for the model materials to work, they need to be changed slightly.

For LightmappedGeneric materials:

1. Change "LightmappedGeneric" to "VertexLitGeneric".
2. Change any "$color" to "$color2".

For UnlitGeneric materials:

1. Add "$model 1" into the shader.
2. Change any "$color" to "$color2".

Sounds

Sounds are organized by national applicability like materials, textures, and models are. So a US-style crossing bell goes in sound/trakpak3_us, and so on.

Lua

Most of the lua stuff that devs and mappers will need to worry about goes in lua/trakpak3. That's where things like signal system definitions and node files are kept. For any lua included with individual maps, the files will go in addons/lua/trakpak3.

Modeling

For visual consistency, it is recommended that Trakpak3 models be made in Hammer, and compiled into models via Propper. If you can make it look visually consistent, you can use any modeling program you like, of course. Hammer makes extensive use of tileable (seamless) textures and many materials per model. Textures should be seamless to the maximum extent possible because of the way textures rendered in source blur pixels together when viewed at a distance. For example, suppose you have a texture consisting of a red block surrounded by black. If you UV map a face to cover only the red block, the face in-game will have black around the edges.

Certain Trakpak3 models (such as switch stands, crossing gates, semaphore signals) should have animations. For that, I make the meshes in Hammer and use Blender to animate them. If you prefer something else, you can go ahead and use that. A guide on how to make Propper models work with Blender (and how to animate them) can be found [HERE, LINK TBA].

The Track

Most Basic Track will be created using John Henry. That includes all straights, arc curves, banked arc curves, Bezier curves, and switches. A full guide to John Henry can be located [HERE, LINK TBA]. It is preferred that you use the SMD export option unless necessary for creating nonstandard track as the SMD option will animate switches for you and is not subject to Hammer's lossy VMF save/load process.

Special Track will have to be manually created. Special Track includes pieces such as bridges, slip switches, diamonds, gauntlet track, turntables, bumpers and wheel stops, etc. Of course, you can use the base track that John Henry spits out to make special track.

Roads

My plan for my own maps is to make roads out of displacements and brushes via the gm_fork method. Of course, this may not be best for everyone, so I do intend on making some road models for general purpose usage.