Train Simulator 2013

New Texture Compression Features

The ‘_nms’ suffix on normal map textures is now available for all materials except TrainLightBumpSpecMask.fx. Use this suffix to get higher quality compressed normal maps.

The ‘_nocomp’ suffix on any texture, forces uncompressed texture export. Use in preference to ‘_nm’ for textures which should not be compressed at all graphics settings in game.

Compression defaults to DXT5 rather than DXT3 for textures with an alpha channel. No action required by art/content. Should give better results for material channels, e.g. Ambient Occlusion and Specular.

Physical Camera Animation

In TS2012, it is not possible to attach the cab camera to an animated node on a body. This is because the cab camera becomes part of the game physics.

In TS2013, you can attach the cab camera to a node on the exterior model. This would allow anything that affects the driver’s seated position on the model to be simulated physically.

In the engine/wagon blueprint, you will see a field under “Rail vehicle component” called “Animated body node name”. Enter the node name in the model that you wish to attach the camera to. When this node is animated, the camera will move relative to the node.

Example Use

  • Adjustable driver seat height.
  • Tilt (where a body node is setup with animated tilt and controlled by script).
  • Allow for more head positions than the default driver and second man views.

Limitations

Rather than manipulating the camera directly (as with the second man view), the animation physically moves the camera. This means any sudden jerks in the animation will be physically noticeable, so avoid sudden changes in the animation for smooth camera transitions.

Carriage Interior Animation

Previously, it was not possible to animate carriage interiors, only cab interiors based on control values. This is no longer the case. Geometry in the carriage interior can be animated the same way as cab geometry.

To animate carriage geometry, under certain interface elements in control values, you can change the output interface from the default Cab to Carriage or Both.

Example Use

  • Animating doors that are visible from a passenger seated position
  • Animating passenger display information
  • Animating tilt
  • Showing a brake pipe pressure gauge visible in a passenger view

Limitations

This does not allow you to manipulate controls in a carriage interior view by mouse, it only allows control values to determine the animation state of geometry.

Moon Phases

The moon texture in a “sky info blueprint” can now be a tiled texture representing a number of moon phases. The phase is based on the date specified in the scenario. The number of phases is specified in the sky info blueprint.

The texture must have as many columns as rows, and the smallest square number of tiles as there are phases. E.g. a texture with 8 phases would require a 3x3 tiled texture, leaving the last tile blank.

Tiles are ordered left to right, top to bottom (i.e. first row has tiles 0, 1 and 2). The first tile (0) must be a new moon, and the middle tile (4) must be a full moon. Every other tile is then the phases between.

Limitations

Each tile must be the same size, and there must be as many rows as columns. For 1 phase (the default for sky info blueprints), a single texture for a full moon is used. For 2 - 4 phases, a 2x2 tiled texture is used. For 5 - 9 phases, a 3x3 tiled texture is used etc. To ensure new moon and full moon phases are present, an even number of phases should be used.

Junction Render Properties

Along with some bug fixes and a lot of optimisation, the network rendering system also has a new junction render property tool. This is designed to act as mitigation for rendering issues such as overlapping rails and frogs.
  • Ctrl double-left-click on a junction to open its properties.
  • A flyout dialogue should appear and the junction will be highlighted in red.
  • Each box controls one of the parameters for the junction.
  • The top three boxes control the frog lengths and insets.
  • The eight boxes in the middle limit up to eight outgoing rail lengths.
  • The 32 checkboxes toggle the visibility of each element.
For example: If two turnouts are very close to each other, the rail from each may overlap. Toggle each checkbox in turn to find the order of the offending rail. The corresponding limit box will limit the length of the rail from its starting point at the junction head. Enter different values to shorten the rail and remove the overlap.

Or: Two crossings adjacent to each other may have overlapping frogs. By toggling off the relevant parts on each junction, a square frog between will be formed. Experiment, nearly all issues can be mitigated at least with this tool.

New OHE Tool

There are 2 new blueprints used in the setup of track gantries for OHLE. There are also changes to the Loft section render blueprint.

Creating a Gantry Blueprint

Create the gantry blueprint in the Blueprint Editor, and set up as follows:
  • Create with a base object, e.g. the main portion of the gantry as the geometry.
  • Add one child per track spanned. If spanning multiple tracks, e.g. add two hanger arm children to span two tracks.
  • Add node entry information for each wire entry/exit point. Nodes should be listed in left to right order with catenary and contact wires in strict pairs.
  • Mark as either Push off or Pull off variety.
  • Setup lofts which support the special curve type ‘Catenary’ and wires.
  • In the loft segment blueprint, choose special curve ‘wire’ or ‘catenary’.
Create a ‘Track Gantry Set Blueprint 2’:
  • The max and min span control the spacing of gantries.
  • The stagger fields control the left right and cornering offsets for the catenary wires.
  • Add a track gantry entry for each gantry type available.
  • Track span is the number of tracks spanned by the gantry.
  • Track span range is the range the gantry can span in metres.
  • Using the ‘Gantry’ tool.
  • Select the tool from the browser.
  • Hovering over a track shows the placement.
  • Repeated left-clicking places selected gantry at auto chosen locations, wires are added automatically where the number of wires matches with the previously placed gantry.
  • The red line is the current track, the yellow selections indicate where an alternate route is available. Press TAB to toggle between available locations.
  • Press SPACE to toggle between auto-validated gantry choices.
  • Right-click once to cancel the current selection and return to manual placement.
  • Choose an option from the fly out without filtering to force full manual placement of a gantry.
  • Adding wires manually.
  • Select the required loft from the lofted object browser.
  • Click the highlighted point on the gantry to start selection.
  • Click a second highlighted point to complete addition of the ribbon.

Irregular Notched Lever Customisation

It is also possible for each notch of an irregular notched control to have a unique colour and name on a labelled / drag slider control. The control value in the control container must have an “Irregular notched lever” interface element. When adding notch data, you are now given the choice between “Notch data” and “Extended notch data”. The new “Extended notch data” allows you to enter a localised name for the notch and a background colour for the text. This is useful for controls where the centre notch is not necessarily neutral, or where a percentage is not clear what the control’s notch actually represents (e.g. 4 state reversers with an additional “off” notch).

No custom HUD controls DLG is required to be set up to display these notches, they will work with the default HUD controls DLG.

Weather Pattern Extension Blueprints

Weather Pattern Extension Blueprints are similar to regular Weather Pattern Blueprints but don’t contain redundant data for specific weather types. This reduces the size of the blueprint down to only what you use.

The Weather Pattern Extension Blueprint’s primary use is to allow types of weather to be triggered (currently through script), and to blend in with the current weather to totally override it. The blueprint also allows for “location events”, allowing upright view facing sprites to be drawn at a location.

Location events also allow one shot sounds to be played and additive ambient light adjustment, though these are currently not location specific and will be heard/be visible anywhere in the world when the event occurs.

The main container required is a “Triggered Weather Event Chain”. This is given a unique name that can be used in a script to initiate the event chain. A triggered weather event chain contains two collections for “Timed Weather Events” and “Location Events”.

A Triggered Weather Event Chain also has a Blend Out Time property. This is needed to blend back into the default weather pattern blueprint’s weather at the end of the event.

The Loop Mode allows 3 different behaviours:
  • Restart - The triggered weather event chain will go on repeat until the script tells it to stop.
  • Hold End - The last “Timed Weather Event” will hold at the end of the event chain until the script tells it to stop. (E.g. if the last Timed Weather Event is light rain, it will continue to rain until the script stops it).
  • Stop - The event will stop after the last event (Timed Weather Event or Location Event) takes place, the script does not need to stop it manually.

Timed Weather Events

A timed weather event contains two pieces of information: “Duration” and “Weather Type”.
  • Duration - is the time in minutes for how long this weather event will take place. Each timed weather event takes place one after the other, much like in the Weather Pattern Blueprint.
  • Weather Type - is a drop down box where you can select weather types you have defined above, allowing you to reuse weather types.

Location Events

  • Name - Used entirely for reference purposes. Not required, but makes the location event more obvious for what it is in the blueprint editor.
  • Delay - How many minutes to pass before this location event occurs.
  • Audio Controller Name - A name for a control in the blueprint’s audio control. This control value is flipped between 1 and 0 when the event triggers to allow a one-shot sound to be set up.
  • Initial Long / Lat - The initial location in the world to draw a sprite.
  • Target Long / Lat - The target location. The sprite will move to this location in a linear motion. For a stationary sprite, just copy the initial long / lat values.
  • Follow Terrain - True if the sprite should move across the surface of the terrain.
  • Height Offset - How much to offset the sprite. If “Follow Terrain” is true, then this is used to offset the sprite from ground level, otherwise, it is used to offset the sprite from a height of 0.
  • Additive Lighting - True if the location event should add to the ambient light of the world, sky and fog. Can be used for screen flashes for lightning.
  • Additive Lighting Colour - Values of red, green and blue (alpha is ignored) to add.
  • Duration - How long the location event should last in minutes. A value of about 0.002 is good for a lightning flash.
  • Texture ID - An ACE file texture for the sprite.
  • Bottom Left UV - The bottom left UV coordinate to use of the texture. Note that the top of a texture is 0 and the bottom is 1, so the true bottom left of the texture is (0, 1).
  • Top Right UV - As above, for the top right UV coordinate.
  • Scale - The sprite texture is assumed to be 1m2. The scale is used to multiply this to the right size for the world, i.e. a scale of 500 and UV size (i.e. top right UV - bottom left UV) of 0.33 x 1 would draw a sprite 165 x 500m.
  • Fade In Time - Time in minutes that the sprite and additive lighting colour fade in.
  • Fade Out Time - Time in minutes to fade out.

Weather Types

Above the Triggered Weather Event Chain container, there is a container for Weather Types. This allows you to create any number of types of weather that aren’t limited to the defaults given by the original Weather Pattern Blueprint.

A Weather Type entry follows almost the same format as a Weather Type in the default Weather Pattern Blueprint, with the following exceptions:
  • Name - This name is used to reference the Weather Type in the “Timed Weather Events” of a “Triggered Weather Event Chain”
  • Glass Weather Effect Boost - A value between 0 and 1 to boost the amount of rain visible on windows. A value of 1 makes visibility more difficult as the glass gets covered up in rain much quicker.
  • Audio Controller Name - A name for a control in the blueprint’s audio control for looping sound. The “Precipitation Density” value is used for the control, and blends in/out with other weather types’ precipitation density.
  • Precipitation and Cloud descriptions are drop-down boxes to select defined precipitation and cloud types further up in the blueprint, as opposed to the predefined names in the default Weather Pattern Blueprint.

Precipitation Descriptions

These are exactly the same as precipitation descriptions in the Weather Pattern Blueprint. The only addition is Name for referencing the precipitation description in a Weather Type.

Cloud Descriptions

As with Precipitation Descriptions, these are identical to Weather Pattern Blueprint Precipitation Descriptions, with the addition of Name for referencing in a Weather Type.

Another change (that is also present in regular Weather Pattern Blueprints) is that the Colour Darkening Intensity property can be pushed past 1 up to 2.5. A value of 1.5 appears dark enough for a heavy storm where headlights help.

Additional Properties

  • Display Name - The name of the blueprint for selecting in the scenario editor.
  • Audio Control - The name of an audio control containing all sounds for this blueprint.

Scripting

A new function has been added, “SetCurrentWeatherEventChain” to allow you to start and stop a “Triggered Weather Event Chain”.
  • SysCall("WeatherController:SetCurrentWeatherEventChain", name)
Where name is the name of the “Triggered Weather Event Chain” you want to start. If the name is blank or omitted then the current “Triggered Weather Event Chain” is stopped.

Scenario Editor

In the scenario editor, edit the scenario properties. There is a new button for “Advanced properties” only available in Editor builds of the game. This currently has a single property for setting a weather pattern extension blueprint from a blueprint set, by default set to “None”.

Example Use

Two examples could be a thunder and lightning storm, or a rainbow that fades in and out slowly over time.

For an example lightning storm, see RSC/TestWeatherStuff/Weather/SanBernadino.xml. All source files used for this are under RSC/TestWeatherStuff.

Limitations

There are a number of limitations that could be removed in future if required:
  • Sounds and additive lighting are currently non-location specific and can be heard and seen from anywhere once triggered.
  • The weather itself is not location specific, for example, areas cannot be defined to be stormy - this would be better implemented properly with a completely new weather system.
  • Once an event chain has started, it will run in sequence and can’t be paused or resumed.
  • Separate event chains cannot be blended together, however, if the above limitation is removed, this can be worked around by combining event chains and defining pause locations in the event.
  • All sprites are currently drawn upright view facing using an unlit shader.

Sound System Changes

The switchover to OpenAL should not have caused any major change in sound from DirectSound for legacy content. The biggest difference is that those who have a non-Creative Labs sound card will also be able to hear environmental effects. The OpenAL implementation runs entirely in software for stability and consistency across the whole user base.

There is a new property in audio proxy controls. “Revision” states whether to use the old legacy distance model pre-TS2013, or the revised distance model in TS2013.

There are only a couple of differences between both:
  • “No further attenuation distance” is completely ignored in v2, as it simply stops a sound from rolling off to silence.
  • The roll-off factor is 1 in v2, as opposed to 1.5 to match DirectSound. This means sounds can be heard at greater distances and don’t roll-off too quickly.
The following affects all sound:
  • Doppler effect is correctly applied to flying cam, taking into consideration camera velocity.
  • Bogie joint sounds are now more accurate. It is no longer assumed that all bogies have two axles; the correct number of axles and distance apart is used.

Reverb and Occlusion

The reverb and occlusion present in TS2012 that could only previously be heard on Creative Labs cards with ALchemy / Windows XP are now available to all users. This has brought to light a few issues that can be resolved in future.

Reverb currently setup on most routes for tunnels and bridges is too extreme. This is not something that has changed in the move to OpenAL, but something that only a few users could hear before.

Some sounds are not occluded as they should be. Most original content is setup correctly to benefit from EAX, but some of the more recent content has not been setup correctly, with certain sounds audible when they shouldn’t be. Engine sounds that have separate interior and exterior versions do not get reverb or occlusion when in the cab.

The code for applying reverb to sounds is currently quite limited and inaccurate for exterior views but works well in the cab. The same was true for EAX on DirectSound.

Only one set of engine sounds needs to be set up, set to both views, not just exterior/interior. The cab occlusion effect will make these sound correct in the cab. This will also help reduce the number of sounds in memory and help prevent sounds cutting out too soon.

Reverb setup in the reverb blueprints needs to be reduced greatly - some have a current delay of 8 seconds!