ETS2 Prefabs overview

Tutorials and quick guides collection is posted in this forum. Forum is read only.

Moderator: Oleg

User avatar
Site Admin
Posts: 14317
Joined: Fri Feb 06, 2004 3:54 am

ETS2 Prefabs overview

Post by Oleg »

Notes on ETS2 version 1.9 and higher:
ETS2 AI was remastered in version 1.9 and higher, so some information in this guide is incorrect or obsolete. Such an information is populated with an additional explanation highlighted in bright blue color. If the only explanation marked states Obsolete, consider an entire description as obsolete, so it's no longer applies. If an extended information is specified, it can either extended previous description, or replace previous term when "(Obsolete)" is specified in the beginning. In case of replacing of description, only last term is considered obsolete.

For example:
Option A is used to specify "A" behavior. It also generates "B" behavior. Obsolete. "B" behavior is not used, "C" behavior applies.
This can be considered as Option A is used to specify "A" behavior. It also generates "B" behavior. in pre-1.9 exports, and as Option A is used to specify "A" behavior. "C" behavior applies. in post-1.9 exports.

  • The summary of changes relevant to patch 1.9 as follows:
  • AI lanes intersections are generated on export, using ID value as priority on a given lane.
  • Some AI lanes options are obsolete. Several AI behavior changes applies to some options. Some options were renamed, while their meaning remains the same.
  • Traffic light profile is specified in traffic light name (before it's index in braces). Using traffic light profile is preferable, as all other options can be omitted, so you can configure and refine options on traffic lights by altering their profile, instead of updating all affected prefabs.

ETS2 Prefab editing including AI lanes, service points, navigation paths.

ZModeler3 allows you to edit and create new prefabs for ETS2. Since prefabs include paths and routes and these are implemented in ZModeler as splines, you should configure ZModeler to work with ETS2 and splines properly.

Open it's Configuration window, locate General properties, expand Splines branch. You should disable "Automatic detalization" there, so all spline segments will have a predefined detalization value. Spline detalization is not used when exporting prefab model, but it might be easier to deal with spline curves in ZModeler with constant detalization value.

Also, enable "Always draw points" option there to force ZModeler draw spline control points as dots even when you work on objects level. It's easier when you see points location all the time. And one more handy option is "Draw direction arrow". It will draw spline direction arrow, so you can easily say which direction spline goes. The size of an arrow is specified in ZModeler units and should be pretty big for prefab editing, so arrows are clearly seen. The suggested value is 2.5 for arrows.

Another very important option you should set is the Compatibility for ZModeler. Once you switch it to "SCS Compatibility" and restart ZModeler, certain options will get a meaningful ETS2-specific names in ZModeler. Otherwise these options might be inaccessible. Also, a "Custom mesh colors" option is very preferable, so imported prefab splines will have different colors initially.

I load the small gas station prefab to show you what we shall deal with. The following image is the visual model of gas station prefab:

And this is the prefab model loaded with it. Prefab model is under prefab branch of hierarchy and includes it's own meaningful branches/groups of spline models and dummy helpers. Names listed here and below are case-insensitive:

The lanes group is a set of AI lanes, it includes splines only. Splines are interconnected with share points to allow AI paths splitting on turns and intersections. The entire group is optional and could be missing (e.g. "farm" or "garage" - prefabs where AI traffic is not available). This group will be described few later.

The nodes group is the most important for prefab and must always exist and contain at least "connector 0". There could be no prefab without nodes, so at least one node for prefab connecting is a must.

Nodes are enumerated from zero upto 5. So, 6 connection points for prefab is available, while 4 is the maximum used by the game to the moment. Each node consist of connector and optionally a border spline. Connector is the actual point where road is connected to prefab, while the border spline specifies a sequence of prefab border points going from this node in counter-clockwise direction. It's not clearly seen on an image, but the border spline goes around prefab in counter-clockwise direction:

The border spline is very specific. Its first several points are merged with lanes head/tail points and after merged points a set of border points goes around prefab. Merged points are not a part of the border, but tells ZModeler which AI lanes starts or ends at respective node. When border spline is not available, or it does not starts on merged points, the associated node will not gain any AI lanes and the game could be unable to connect incoming/outgoing road lanes. On the image above the border spline shares two points with outgoing lanes (traffic will go away from these lanes onto connected road), followed immediately by two shared points with incoming lanes (traffic will come from road lanes onto these points into prefab). And straight after them the first non-merged point goes (it's marked as "actual in-game border will start here").

Non-merged border points go straight to the end of respective prefab border, assuming the game will create polygons from this border to the side away from prefab. The following images shows how scenery is joined to prefab using border points:

Nodes and borders are quite simple and you will get used to this logic after examining dozen of original prefab models.

The next prefab group is entitled lights and include placeholders for traffic lights. Each entry is a dummy node with optional name given: for example road cross prefab usually define traffic light name as "City". The name specifies profile to use for a given traffic light. The name (if available) is followed by light ordinal index in braces. Indices should go straight from 0. So lights indexed 0,1,2,3 are Ok, but 0, 2, 3, 4 or 1, 4, 5 are not good. The order of dummy nodes in a list is not significant.

The image shows properties of traffic lights. You should assign these properties manually and they are as follows:
0 (or missing property): is a default city traffic light.
1: traffic light is triggered by player (e.g. tollgate).
2: traffic light is triggered by mover proximity (e.g. train will turn on cross-road traffic light).

0 (or missing property): default light type (Obsolete). Light profile (name) is used in such a case, so other settings are ignored.
1: automatic traffic light (most common case for road crossing city lights)
2: automatic barrier (tollgate) - will include collision obstacle too.
3: places a model only and has no effect on AI.
4: small version of the model (e.g. minor variant of cross-road animated light and barrier)
5: big version of the model (e.g. major variant of cross-road animated light and barrier)

Timing followed by four time intervals in seconds specifies time phases for traffic light. This property is a must (Obsolete). When profile type is used and specified, property can be omitted. The meaning of timing values is phases in seconds: red, orange, green, orange.

Property names are case-insensitive.

The following two groups are quite similar: services and zones. Services group contains dummy nodes with a numeric names. Each number has it's own meaning for the game and it will place a marker with respective service at a given point. For example, 3 is a petrol service, 10 is a parking or resting place.

Zones group contains closed spline chains, with specific names. Each chain specifies a zone that user can drive into to trigger some action. See def\world\trigger_action.sii for more details. So far seen names are:
Hud_parking - parking zone; Cam7_on_off - toggles cinematic camera when user enters an area.

Locators group contains dummy nodes that will be replaced by sign model. The name of each dummy contains a numeric value of associated sign and optionally a visual model name to show, mostly "Vis" in braces. When model name is not defined, "Vis" is exported.
Sign numeric values can be located in def/world/sign.sii for a reference.

AI Lanes:
The lanes group contains splines for AI lanes. This one should be paid a high attention and accuracy when editing. First of all, spline direction specifies direction of AI movement along the spline. Each spline point must be Bezier-corner or Bezier. It should not be of type Corner! There is no need to place too much spline points, since the game will interpolate movement of AI traffic over the spline segment.

What you should pay attention to is the spline points merging. When several lanes come to a single point, they should have a merged (shared) point there. Shared points are generally drawn in pink color by default (this can be overridden by ZModeler settings). And the most important is that spline segments overlapping is prohibited. Splines could cross one over another, can lead into single merged point or start from a single point (split), but they can't define a completely or partly overlapping segments. Note, there is no need to lead a full lane from beginning of prefab to the end: on the image above one AI lane on gas station starts at split point on another AI lane and then merges into that lane again. A sort of alternate route from one point to another.

Spline points (accessible on manipulators level) store most of AI logic and can be assigned different properties. Note, point property specifies properties of spline segment starting from this point. First of all, a user-defined property "speed" will limit AI speed on a spline curve that starts at a given point. Additionally, a General->External State->SCS Compatibility branch includes a dozen of flags you can apply to a point to describe AI behavior on a spline curve segment. I'll explain meaning of these options few later. There is one important thing to note first:

On the image above you can see properties of the point of the rightmost AI path spline. As you can see, this point is pink and it is merged with another spline curve (there are two lanes on a gas station). Merged points share a position only, but they are still a different points, with their own settings and options. Thus, when traffic reaches this point, it has two different ways to go - the rightmost path and the one next to it. The rightmost path (shown on image above) point specifies an option "No trucks allowed", so truck with trailer will not go this way.

On the other hand, the properties for the same point on another spline/path are different and shows "Trucks only", so trucks will chose this lane.

Options you can apply have the following meaning:
Give way: AI will give way to vehicles coming from other lanes. This option can only be used in combination with "Intersection ahead" (Obsolete). Priority management is used with respect to priority values set in ID field, so this property is no longer available.
Trucks only: The following curve should be used by trucks with trailers only. For example, it can define a slightly different trajectory of turn, so trucks can perform turn safely without collisions to street lamps or other obstacles. Option renamed to No small vehicles
No trucks allowed: Truck with trailer will not go this way if possible (will chose another route if any other spline is merged at a given point. Option renamed to No large vehicles
Player only: The path is used by player only, AI will not go the given way. (seen on some roundabouts cross variants). Obsolete: use combination of No small vehicles and No large vehicles to indicate a lane for player only. Creating a lanes for player only is a must, so AI traffic can predict player movement across the prefab.
Right blinker and Left blinker will make AI turn on right- or left- turn signal. This option gains advantage to AI against other AIs coming from different directions (when combined with "Intersection ahead") Priority / Advantage is obsolete as priority management uses priority values specified in ID field.
No blinker advantage - Will not gain advantage against other AI when used with "Right blinker" or "Left blinker". (Obsolete)
Rare usage - reduces probability of using a given route (e.g. lanes leading to gas station).
Intersection ahead - Prior or at reaching the next point, the curve will have an intersection. So, if there are joining lanes on next control point, both should have "intersection ahead". If certain lanes cross one another (even with no points) on upcoming curve segment, "Intersection ahead" should also be used. Often comes with "Give way" option to assign lower priority to one of intersecting curves, otherwise AI collisions will occure. (Obsolete). The filter will automatically detect all intersections on prefab, so this option is no longer available
Traffic light control - AI movement at the end of respective curve segment is controlled by traffic light. The next control point must contain user-defined property Light with the index of respective traffic light. Note, generic road intersections might not define option "Traffic light control" and contain user-defined property Light to bind lane point to a traffic light. The "Traffic light control" option is usually preceding a manually-triggered traffic light controllers (e.g. tollgates, gas stations).

The image below shows a new set of options. You can see some options listed above are obsolete (and missing) and some were renamed as described earlier:


The highlighted row with ID value is now used as priority value for the segment. You should use non-zero priority values on intersecting segments, so in-game AI will pass over intersecting lanes with correct priority. Cross-intersection must have non-zero ID (priority) value assigned on all segments on a given intersection. When several lanes are merging into one point, non-zero ID (priority) is a must too, but you can assign the same priority on all segments, so "lanes zip merging" scenario will be used. Priority values are in range 1..15

As mentioned above, beside "Speed" user-defined property, Light user-defined property specifies the index of traffic light that AI on a given segment should respect.

I'll show you how to create AI lanes and assign properties. Say I want traffic to make a U-turn after gas station:
First, I add a control point on a target spline, so I have the point where newly-created spline will end up with merge. It's preferable to have points on target splines created before you start drawing a new spline.
I use Strip tool located in Create\Spline branch of commands bar. Click on existing AI path point and drag direction line aside, so curvy segment will be created. Then specify Weld + new spline, so newly-created spline has a merged point initially. Note, when you click on existing spline points during creation, the tool will highlight in pink color the point where it can perform merge for you.
Then I click and drag to specify some intermediate extra point.
Then click and drag over target point where U-turn will merge the AI lane on the opposite road. And pick Weld and stop. The newly-created spline is merged at the beginning and at the end-point.
I drag&drop newly-created object named "Spline" into "Lanes" group, so ZModeler will consider it as AI lane on export.

Before assigning properties, I add points on straight AI lanes that newly-created spline has crossed. This step is needed to be able to apply "intersection ahead" property on these lanes. Otherwise, the traffic going straight will not be warned about potential collision (the collision is still possible):

As you see, I've added point on each straight lane prior to potential intersection, then selected all these points (actually five points were selected, including the starting point of new segment), assigned Intersection ahead option and pressed apply. Traffic is aware about intersection, but no advantage assigned.

I enable "Give way" option on the very first point only, so turning AI will give way to AI going straight. Then turning AI will go into merging section with no advantage and could have potential collision with AI going straight in opposite direction. This situation is just an example for you to understand what would happen when certain options are not assigned. Also, you can notice I've toggled "Left blinker" and "No blinker advantage" options, so traffic will turn left turn signal prior to making U-turn, but this blinker will not give advantage and traffic will still need to wait for clear way to go.

On the image above you can see a truck trying to go the newly-created route after filling at gas station, yup it goes through the barrier, but it's not the point we are discussing here.

Navigation: Map and GPS:

The final branch to discuss is navi. The GPS navigator and UI map helper objects are placed here. It can contain splines only and splines could be ether: Closed spline is considered as area or polygon to draw on GPS/map screen, non-closed spline is a navigation path.

Closed splines could have only four points, so it makes a shape of "quad polygon". The game does not triangulate complex shapes, so if you need to draw a complex polygon, make it out of several simple "quad poly" splines. Closed poly-spline can have the following options in user-defined options box:
0 (or missing property): default orange color, same color as the road on map;
1: use bright color (bright grey on unexplored areas, sand-yellow on explored areas);
2: use dark color (dark grey on unexplored areas, brown on explored areas);
3: use green color (grass or other green areas on map)
Over (set value 1 to enable) - renders poly on top of other polygons. Usually assigned on polygons that form the boundaries of map objects located on prefab area; this option is not set on polygons that cover the entire area of prefab.
Border - toggles on dark outline of polygon.

Non-closed splines are considered as navigation path, or a "road". (On the image above I've moved the lane aside so you can see it). These path-splines can contain the following settings:
Width - is the road width in "lanes":
0 (or missing property) is a single lane thin road
1 - one lane in each direction
2 - two lanes in each direction
3 - three lanes in each direction
4 - four lanes in each direction

Offset - is the offset (in meters) or gap between opposite directions. There could be zero (missing property) or the following values: 1,2,5,10,15,20 and 25. Other values are ignored.

User-defined properties on points of path splines are more important to discuss. These can suppress settings of spline and alternatively can assign extra options:
link - the navigation point is linked to a node with specified index. Thus, when you drive to prefab from a road connected to node 0, GPS will try to build route starting from navigation paths that has points with "link 0" specified. If your navigation path points have no link property at all, your paths are useless to GPS, since it will be unable to lay routes. Only border navigation points can specify "link" property, it's not allowed to apply it on the inner navigation points.
route - specifies which nodes can be reached from this point. This property is very tricky in usage and I'll explain it in details. First of all, you can remove this property on all your path spline points: in such a case, ZModeler will try to determine routing automatically, using just the "link" property and direction of navigation path splines. This works fine in most of cases, so it can be used safely. Unfortunately, it will not work properly in case of round-about road crossing where loop can occur.

Navigation paths are very-alike AI lanes and connected on shared points. But each navigation line is considered by GPS as bi-directional. It will ignore direction of the spline in ZModeler and can lay route in a wrong road direction unless you help it to lay routes correctly. Lets study a small example on round-about cross given above. It has the following nodes configuration:

Consider I want to make a UK version out of this prefab, so route from node #1 to node #0 is laid like in UK. First of all I select all paths, switch them to points (manipulators) level, select them all and explore their properties. I delete property route and press Apply, so the "route" property is removed on all points in navigation.

The GPS routing goes straight without any hint until it reaches a point with multiple directions. The image explains the situation. Routing reaches the point and can go in three directions: the one to Node #2, one to roundabout in clock-wise direction and one to roundabout in counter-clockwise direction.

I select the point straight after "confusing" point in clock-wise direction and assign property route on it with value 0,1, meaning that "go to this point from confusing point to reach node #0 or node #1". I don't set any property on a point that goes in counter-clockwise direction, so GPS will not try to go there given a hint on another points. Of cause, the point leading to node #2 should have "route 2" hint, so GPS will not be confused at all - node #2 is reached on left direction, other nodes (#0 and #1) are reached on clockwise direction, so counter-clockwise direction will not be used.

It might be tricky to understand, but take a look at the full image with complete ready and properly-configured routing hints. Route property is set on red-marked points only, and green-marked points specify navigation points that caused me to apply "route" property on nearby points.

The following image is an in-game test of updated prefab routing:
You can see the EU version of roundabout prefab is located in game, but GPS suggests me a UK routing path over it.

The final note on navigation paths is a set of "low resolution" paths. These paths are hidden after import and they create a variant of low-resolution routes navigation. The game will use them when you zoom-out, so it will not need a detailed prefab routing to be drawn. Instead, a roundabout cross section shown above will be routed and drawn on map as the following intersection:

I've highlighted path lines so you can see them clearly. Of cause the border points should have correct link property assigned. The path splines should have a user-defined property lowres assigned (set value 1) on it.

Note, low-resolution navigation paths must be at the bottom of "navi" branch. Otherwise, GPS might will find them first as suitable routing and will draw you navigation route using low-resolution paths even on a high zoom. As you can see on an image, they are paths #1,#2 and #3, but they are moved to the bottom of the list to be exported properly.