ACS Coupling System

2023-07-06T00:37:46Z

Dundun92: /* Pipes for Air Brakes */

===Introduction===

There are many and varied problems with the existing BlueStar standard - but the main ones are the inflexibility beyond the initial application (coupling mineral wagons and transition era locos), and the rather arcane numeric values put into the config.txt.

A more readable, more flexible, and preferrably easily extensible datastructure in the config.txt was needed, and some way of standardising the logic (at the very minimum, an include file, but preferrably a library). It needed to support many more different types of coupler, vehicles with different couplers on each end, and so on.

The ACS System is an extension of the BlueStar coupling standard for TRS models (effectively BlueStar V2) and provides for the effect of working couplings on rolling stock. From version 5 of the ACSLib ACS vehicles are compatible with older BlueStar/CoupleStar ones.

To add ACS couplings it is necessary to edit the asset config file, add attachment points to the mesh (see below for an alternative which can sometimes be used) and to create a script or edit the existing one. Due to the fact that you need access to the source files of the asset and to be able to script it is an advanced technique that cannot easily be carried out by an end-user.

For couplers implemented as meshes in the mesh-table (usually but not always animated), position and orientation tags can be used to locate the attached meshes:

*For front couplings the tag 'position 0,Y,0' should be added.
*For back couplings two tags are needed, 'position 0,Y,0' and orientation '0,0,3.14159'
*in both cases the value Y is 0.46 metres inboard of the Y value of limfront and limback respectively.

===The Attachment Points===

All of the coupler, hoses and cables are attached to two points, one on the face of the front buffer beam (a.couple0) and one on the face of the rear beam (a.couple1). a.limfront should be 0.46m forward of a.couple0 and a.limback 0.46m rearward of a.couple1. a.couple0 and a.couple1 must be at x=0 and z=0.

Create a.couple0 in top view and move it into position. Then clone and position it to create a.couple1 and rotate it 180°. The Y axis of the two coupler points should point towards 0,0,0.

[[File:Acs attachments.png|border|middle|x375px]]

===The Config File===
First off, here is an example config.txt fragment:

<pre>
extensions {
max_permitted_speed-60850 "125mph"
active-coupling-standard-60850 {
version-major "2"
version-minor "0"
brakes "air"
front {
coupler "knuckle|screwlink|hook"
gangway "gangway"
airbrake "twin"
vacbrake "none"
multiple-working "none"
heating-type "electric"
rch "high"
}
back {
coupler "knuckle|screwlink|hook"
gangway "gangway"
airbrake "twin"
vacbrake "none"
multiple-working "none"
heating-type "electric"
rch "high"
}
}
}
</pre>

So, what does all this do, and what are the options?
====Extension Container====
<pre>
extensions {
...
}
</pre>

This is for TRS2006 compatibility - it's all going in the extensions container. This does work in TRS2004 as well. Watch for the caveat at the end though...

====Max Permitted Speed====
<pre>
Max_Permitted_Speed-60850 "125mph"
</pre>

Not strictly part of the coupling code, but may as well mention it. This is for the Max Permitted Speed rule to tell how fast this vehicle should be permitted to travel. It will tell both AI drivers and the human driver (via the Custom HUD rule) what the maximum permitted speed is for the train they are driving, based on information from each vehicle. (And in a future version of the rule, more stuff too...)
====ACS Container====
<pre>
active-coupling-standard-60850 {
...
}
</pre>

This is the container within which all the config information will be held.

====ACS Version====
<pre>
version-major "2"
version-minor "0"
</pre>

Version numbers. This is useful when later code needs to read earlier format config files. Should make extending the standard a lot easier.

====Braking System====
<pre>
brakes "air"
</pre>

Defines what type of braking system is fitted to this vehicle. Options are:
*"air"
*"vac"
*"dual"
*"none"

This is independant of what hoses are available - unbraked but through piped stock is an entirely possible combination, and is representable.

====Position====
<pre>
front {
...
}
back {
...
}
</pre>

Containers for the front and back of the vehicle. 'Front' is defined as "the a.limfront end", and 'back' "the a.limback end". Available options for both are the same, so I'll describe them just once.
====Coupler Type====
<pre>
coupler "knuckle|screwlink|hook"
</pre>

What type of coupler do we have on this end of the vehicle? Options are:
* "hook" -- connects to screwlink/instanter/3link/hst-emergency-bar.
* "3link" -- connects to hook.
* "instanter" -- connects to hook.
* "screwlink" -- connects to hook.
* "hst-emergency-bar" -- connects to hook.
* "bar-full" -- connects to "bar-none". Half of a handed pair for when one vehicle has the entire bar coupling.
* "bar-none" -- connected to by "bar-full". The other half of the handed pair.
* "bar" -- connects to self only. Used when both vehicles have half the bar coupling.
* "knuckle" - standard knuckle coupler.
* "tightlock" -- different to a standard knuckle, refers to a knuckle style coupler often fitted to multiple unit trains that also include electrical connections.
* "wedgelock" -- London Underground coupler.
* "bsi" -- Found on Sprinter DMUs and derived designs.
* "dellner" -- Also compatible with scharfenberg coupling.
* "scharfenberg" -- Also compatible with dellner coupling.
* "(other string identifier)" -- Any string that is not recognised from the above list is assumed to be a symmetrical meet-in-the-middle type of coupler.

Certain couplers are purely compatible with other identical couplers, others are inter-compatible. Some produce handed pairs - e.g. a 3 link chain couples to a hook, and wagons with this coupling are typically fitted with both a hook and a chain.

Multiple coupler options can be specified, and are separated with a vertical bar character. The earlier option is used in preference, so list the best coupler option first.

A typical unfitted freight wagon with a 3 link coupling is specified as "3link|hook". A vehicle fitted with a knuckle, screwlink and hook (e.g. a swingknuckle fitted locomotive) is specified as "knuckle|screwlink|hook". A BR coaching stock dropknuckle (a knuckle and a hook, but no chain) is specified as "knuckle|hook". If the vehicle also has an emergency screwlink which is not permanently fitted, then "knuckle|hook|screwlink" would be appropriate -- this would cause ACS to prefer the chain type coupler from the adjacent vehicle rather than using the emergency screwlink, which would only be used when necessary. A Victorian Railways transitional coupler (which has a chain and a knuckle, but no hook) is specified as "knuckle|3link".

Dellner and Scharfenberg couplings are treated as compatible, so a dellner will also couple to a scharfenberg.

If your coupler type isn't listed, define a standard name for it, and start using it. ACS supports arbitrary extension - any new coupler it hasn't seen before will be treated as a symmetrical coupler. ACS will tell you if it has connected to an identical coupler on the adjacent vehicle.

If you need a new handed pair type (where the coupler on the end of one wagon is not the same as that on the end of another), then you will need to contact the ACS author to get one added.

====Gangways====
<pre>
gangway "gangway"
</pre>

Passenger gangway between vehicles. Options are:
*"none"
*"rubbing-plate"
*"gangway"

This is really intended for coaching stock - it is assumed that all gangways are compatible. I've been considering a 'one piece' gangway option - to aid with the centre of multiple unit trains, where there is no separation point (it will help with deciding which vehicle should display the gangway) - but I'm not sure whether this is of sufficient benefit to include, as it involves a whole new set of logic here that most people won't use, and for the cases it is interesting, the same person has made both vehicles, and can therefore do it themselves... Comments please.
====Pipes for Air Brakes====
<pre>
airbraketype "single"
airbrakeside "left"
</pre>

Brake pipes for air brakes. Options for airbraketype are:
*"twin"
*"single"
*"none"
Twin is the UK standard two pipe air brake system (train pipe and brake pipe). Single is the US standard air brake system where reservoirs are charged from the brake pipe rather than the train pipe (this has appeared on some modern freightcars for reasons unknown, so is included).

Options for airbrakeside are:
*"left"
*"right"
Most traincars (UK, US, etc.) use left-sided airbrakes, so airbrakeside "left" will generally be used, but the right option was added to support both left and right-handed brake pipes on Australian content.

====Pipes for Vac Brakes====
<pre>
vacbrake "none"
</pre>

Brake pipes for Vacuum brakes. Options are:
*"twin"
*"single"
*"high"
*"none"

Single is the UK default for fitted stock, high connections seems to be the standard on UK steam locos. Twin pipes (operating at two different vacuum levels) has been tried in the UK - and while not much fitted stock has the twin pipe system, most air brake, through vac piped stock seems to have two vac pipes.
====Multiple Working Cables====
<pre>
multiple-working "none"
</pre>

Multiple working connections. Options are:
*"(color)-(shape)" -- e.g. "blue-star" or "red-diamond", etc
*"AAR" -- as used on GM locos
*"SR27" -- bagpipes
*"(other identifier string e.g. classname)"
====Train Heating====
<pre>
heating-type "electric"
</pre>

Coach heating. Options are:
*"none"
*"steam"
*"electric" -- standard ETH
*"dual" -- both Steam and standard ETH
*"southern-electric" -- The Southern, who pioneered electric train heating in the UK, fitted heating that was compatible with their DC powered EMUs, and thus ran from the same voltage as the DC power supply. When the rest of BR went ETH, different standards were adopted, resulting in the Southern having a different and incompatible ETH standard...

====Lighting Control Cables====
<pre>
rch "high"
</pre>

Through wiring for lighting control, to the Railway Clearing House standard. Also used more recently for other things - e.g. remote control via various methods - including TDM. I believe it is also used for signals to control doorlocks on stock so fitted - though I could be wrong on this. Options are:
*"high" -- positioned as is fairly standard on coaching stock
*"low" -- positioned as is fairly standard on streamlined locos, e.g. the front of a DVT, or a cl90
*"none"
====Notes====
For all of these where "none" is an option, entirely missing out that line is equivalent to stating "none". This should make stock which doesn't use most of the features much more palatable to produce. This will also help when extending the standard - as new features will automatically be assumed to be not present on stock built to older standards...

That's all very well and good, but how is this supposed to be backwards compatible with the old bluestar standard?

I'm making the code fall back to reading the old config entries if it can't find the new ones. The real problem is that new stock will also have to include config.txt entries for the old bluestar, so that old vehicles know what to do when they couple to this one. Yes, this means that the old tags will never actually go away, but at least TRS2006 doesn't whinge about them so hard as of SP1...

===The Script===

(under construction)

[[Category:Modeling]]

ACS Coupling System

2023-07-05T21:18:30Z

Dundun92: /* The Attachment Points */

===Introduction===

There are many and varied problems with the existing BlueStar standard - but the main ones are the inflexibility beyond the initial application (coupling mineral wagons and transition era locos), and the rather arcane numeric values put into the config.txt.

A more readable, more flexible, and preferrably easily extensible datastructure in the config.txt was needed, and some way of standardising the logic (at the very minimum, an include file, but preferrably a library). It needed to support many more different types of coupler, vehicles with different couplers on each end, and so on.

The ACS System is an extension of the BlueStar coupling standard for TRS models (effectively BlueStar V2) and provides for the effect of working couplings on rolling stock. From version 5 of the ACSLib ACS vehicles are compatible with older BlueStar/CoupleStar ones.

To add ACS couplings it is necessary to edit the asset config file, add attachment points to the mesh (see below for an alternative which can sometimes be used) and to create a script or edit the existing one. Due to the fact that you need access to the source files of the asset and to be able to script it is an advanced technique that cannot easily be carried out by an end-user.

For couplers implemented as meshes in the mesh-table (usually but not always animated), position and orientation tags can be used to locate the attached meshes:

*For front couplings the tag 'position 0,Y,0' should be added.
*For back couplings two tags are needed, 'position 0,Y,0' and orientation '0,0,3.14159'
*in both cases the value Y is 0.46 metres inboard of the Y value of limfront and limback respectively.

===The Attachment Points===

All of the coupler, hoses and cables are attached to two points, one on the face of the front buffer beam (a.couple0) and one on the face of the rear beam (a.couple1). a.limfront should be 0.46m forward of a.couple0 and a.limback 0.46m rearward of a.couple1. a.couple0 and a.couple1 must be at x=0 and z=0.

Create a.couple0 in top view and move it into position. Then clone and position it to create a.couple1 and rotate it 180°. The Y axis of the two coupler points should point towards 0,0,0.

[[File:Acs attachments.png|border|middle|x375px]]

===The Config File===
First off, here is an example config.txt fragment:

<pre>
extensions {
max_permitted_speed-60850 "125mph"
active-coupling-standard-60850 {
version-major "2"
version-minor "0"
brakes "air"
front {
coupler "knuckle|screwlink|hook"
gangway "gangway"
airbrake "twin"
vacbrake "none"
multiple-working "none"
heating-type "electric"
rch "high"
}
back {
coupler "knuckle|screwlink|hook"
gangway "gangway"
airbrake "twin"
vacbrake "none"
multiple-working "none"
heating-type "electric"
rch "high"
}
}
}
</pre>

So, what does all this do, and what are the options?
====Extension Container====
<pre>
extensions {
...
}
</pre>

This is for TRS2006 compatibility - it's all going in the extensions container. This does work in TRS2004 as well. Watch for the caveat at the end though...

====Max Permitted Speed====
<pre>
Max_Permitted_Speed-60850 "125mph"
</pre>

Not strictly part of the coupling code, but may as well mention it. This is for the Max Permitted Speed rule to tell how fast this vehicle should be permitted to travel. It will tell both AI drivers and the human driver (via the Custom HUD rule) what the maximum permitted speed is for the train they are driving, based on information from each vehicle. (And in a future version of the rule, more stuff too...)
====ACS Container====
<pre>
active-coupling-standard-60850 {
...
}
</pre>

This is the container within which all the config information will be held.

====ACS Version====
<pre>
version-major "2"
version-minor "0"
</pre>

Version numbers. This is useful when later code needs to read earlier format config files. Should make extending the standard a lot easier.

====Braking System====
<pre>
brakes "air"
</pre>

Defines what type of braking system is fitted to this vehicle. Options are:
*"air"
*"vac"
*"dual"
*"none"

This is independant of what hoses are available - unbraked but through piped stock is an entirely possible combination, and is representable.

====Position====
<pre>
front {
...
}
back {
...
}
</pre>

Containers for the front and back of the vehicle. 'Front' is defined as "the a.limfront end", and 'back' "the a.limback end". Available options for both are the same, so I'll describe them just once.
====Coupler Type====
<pre>
coupler "knuckle|screwlink|hook"
</pre>

What type of coupler do we have on this end of the vehicle? Options are:
* "hook" -- connects to screwlink/instanter/3link/hst-emergency-bar.
* "3link" -- connects to hook.
* "instanter" -- connects to hook.
* "screwlink" -- connects to hook.
* "hst-emergency-bar" -- connects to hook.
* "bar-full" -- connects to "bar-none". Half of a handed pair for when one vehicle has the entire bar coupling.
* "bar-none" -- connected to by "bar-full". The other half of the handed pair.
* "bar" -- connects to self only. Used when both vehicles have half the bar coupling.
* "knuckle" - standard knuckle coupler.
* "tightlock" -- different to a standard knuckle, refers to a knuckle style coupler often fitted to multiple unit trains that also include electrical connections.
* "wedgelock" -- London Underground coupler.
* "bsi" -- Found on Sprinter DMUs and derived designs.
* "dellner" -- Also compatible with scharfenberg coupling.
* "scharfenberg" -- Also compatible with dellner coupling.
* "(other string identifier)" -- Any string that is not recognised from the above list is assumed to be a symmetrical meet-in-the-middle type of coupler.

Certain couplers are purely compatible with other identical couplers, others are inter-compatible. Some produce handed pairs - e.g. a 3 link chain couples to a hook, and wagons with this coupling are typically fitted with both a hook and a chain.

Multiple coupler options can be specified, and are separated with a vertical bar character. The earlier option is used in preference, so list the best coupler option first.

A typical unfitted freight wagon with a 3 link coupling is specified as "3link|hook". A vehicle fitted with a knuckle, screwlink and hook (e.g. a swingknuckle fitted locomotive) is specified as "knuckle|screwlink|hook". A BR coaching stock dropknuckle (a knuckle and a hook, but no chain) is specified as "knuckle|hook". If the vehicle also has an emergency screwlink which is not permanently fitted, then "knuckle|hook|screwlink" would be appropriate -- this would cause ACS to prefer the chain type coupler from the adjacent vehicle rather than using the emergency screwlink, which would only be used when necessary. A Victorian Railways transitional coupler (which has a chain and a knuckle, but no hook) is specified as "knuckle|3link".

Dellner and Scharfenberg couplings are treated as compatible, so a dellner will also couple to a scharfenberg.

If your coupler type isn't listed, define a standard name for it, and start using it. ACS supports arbitrary extension - any new coupler it hasn't seen before will be treated as a symmetrical coupler. ACS will tell you if it has connected to an identical coupler on the adjacent vehicle.

If you need a new handed pair type (where the coupler on the end of one wagon is not the same as that on the end of another), then you will need to contact the ACS author to get one added.

====Gangways====
<pre>
gangway "gangway"
</pre>

Passenger gangway between vehicles. Options are:
*"none"
*"rubbing-plate"
*"gangway"

This is really intended for coaching stock - it is assumed that all gangways are compatible. I've been considering a 'one piece' gangway option - to aid with the centre of multiple unit trains, where there is no separation point (it will help with deciding which vehicle should display the gangway) - but I'm not sure whether this is of sufficient benefit to include, as it involves a whole new set of logic here that most people won't use, and for the cases it is interesting, the same person has made both vehicles, and can therefore do it themselves... Comments please.
====Pipes for Air Brakes====
<pre>
airbraketype "single"
airbrakeside "left"
</pre>

Brake pipes for air brakes. Options for airbraketype are:
*"twin"
*"single"
*"none"
For airbraketype, twin is the UK standard two pipe air brake system (train pipe and brake pipe). Single is the US standard air brake system where reservoirs are charged from the brake pipe rather than the train pipe (this has appeared on some modern freightcars for reasons unknown, so is included).

Options for airbrakeside are:
*"left"
*"right"
For airbrakeside, most traincars (UK, US, etc.) use left-sided airbrakes, so airbrakeside "left" will generally be used, but the right option was added to support both left and right-handed brake pipes on Australian content.

====Pipes for Vac Brakes====
<pre>
vacbrake "none"
</pre>

Brake pipes for Vacuum brakes. Options are:
*"twin"
*"single"
*"high"
*"none"

Single is the UK default for fitted stock, high connections seems to be the standard on UK steam locos. Twin pipes (operating at two different vacuum levels) has been tried in the UK - and while not much fitted stock has the twin pipe system, most air brake, through vac piped stock seems to have two vac pipes.
====Multiple Working Cables====
<pre>
multiple-working "none"
</pre>

Multiple working connections. Options are:
*"(color)-(shape)" -- e.g. "blue-star" or "red-diamond", etc
*"AAR" -- as used on GM locos
*"SR27" -- bagpipes
*"(other identifier string e.g. classname)"
====Train Heating====
<pre>
heating-type "electric"
</pre>

Coach heating. Options are:
*"none"
*"steam"
*"electric" -- standard ETH
*"dual" -- both Steam and standard ETH
*"southern-electric" -- The Southern, who pioneered electric train heating in the UK, fitted heating that was compatible with their DC powered EMUs, and thus ran from the same voltage as the DC power supply. When the rest of BR went ETH, different standards were adopted, resulting in the Southern having a different and incompatible ETH standard...

====Lighting Control Cables====
<pre>
rch "high"
</pre>

Through wiring for lighting control, to the Railway Clearing House standard. Also used more recently for other things - e.g. remote control via various methods - including TDM. I believe it is also used for signals to control doorlocks on stock so fitted - though I could be wrong on this. Options are:
*"high" -- positioned as is fairly standard on coaching stock
*"low" -- positioned as is fairly standard on streamlined locos, e.g. the front of a DVT, or a cl90
*"none"
====Notes====
For all of these where "none" is an option, entirely missing out that line is equivalent to stating "none". This should make stock which doesn't use most of the features much more palatable to produce. This will also help when extending the standard - as new features will automatically be assumed to be not present on stock built to older standards...

That's all very well and good, but how is this supposed to be backwards compatible with the old bluestar standard?

I'm making the code fall back to reading the old config entries if it can't find the new ones. The real problem is that new stock will also have to include config.txt entries for the old bluestar, so that old vehicles know what to do when they couple to this one. Yes, this means that the old tags will never actually go away, but at least TRS2006 doesn't whinge about them so hard as of SP1...

===The Script===

(under construction)

[[Category:Modeling]]

File:Acs attachments.png

2023-07-05T21:14:31Z

Dundun92: A List of attachments needed for the ACS coupling system.

A List of attachments needed for the ACS coupling system.

ACS Coupling System

2023-07-05T20:51:24Z

Dundun92: /* Pipes for Air Brakes */

===Introduction===

There are many and varied problems with the existing BlueStar standard - but the main ones are the inflexibility beyond the initial application (coupling mineral wagons and transition era locos), and the rather arcane numeric values put into the config.txt.

A more readable, more flexible, and preferrably easily extensible datastructure in the config.txt was needed, and some way of standardising the logic (at the very minimum, an include file, but preferrably a library). It needed to support many more different types of coupler, vehicles with different couplers on each end, and so on.

The ACS System is an extension of the BlueStar coupling standard for TRS models (effectively BlueStar V2) and provides for the effect of working couplings on rolling stock. From version 5 of the ACSLib ACS vehicles are compatible with older BlueStar/CoupleStar ones.

To add ACS couplings it is necessary to edit the asset config file, add attachment points to the mesh (see below for an alternative which can sometimes be used) and to create a script or edit the existing one. Due to the fact that you need access to the source files of the asset and to be able to script it is an advanced technique that cannot easily be carried out by an end-user.

For couplers implemented as meshes in the mesh-table (usually but not always animated), position and orientation tags can be used to locate the attached meshes:

*For front couplings the tag 'position 0,Y,0' should be added.
*For back couplings two tags are needed, 'position 0,Y,0' and orientation '0,0,3.14159'
*in both cases the value Y is 0.46 metres inboard of the Y value of limfront and limback respectively.

===The Attachment Points===

All of the coupler, hoses and cables are attached to two points, one on the face of the front buffer beam (a.couple0) and one on the face of the rear beam (a.couple1). a.limfront should be 0.46m forward of a.couple0 and a.limback 0.46m rearward of a.couple1. a.couple0 and a.couple1 must be at x=0 and z=0.

Create a.couple0 in top view and move it into position. Then clone and position it to create a.couple1 and rotate it 180°. The Y axis of the two coupler points should point towards 0,0,0.

[[image:acs att points.jpg]]

===The Config File===
First off, here is an example config.txt fragment:

<pre>
extensions {
max_permitted_speed-60850 "125mph"
active-coupling-standard-60850 {
version-major "2"
version-minor "0"
brakes "air"
front {
coupler "knuckle|screwlink|hook"
gangway "gangway"
airbrake "twin"
vacbrake "none"
multiple-working "none"
heating-type "electric"
rch "high"
}
back {
coupler "knuckle|screwlink|hook"
gangway "gangway"
airbrake "twin"
vacbrake "none"
multiple-working "none"
heating-type "electric"
rch "high"
}
}
}
</pre>

So, what does all this do, and what are the options?
====Extension Container====
<pre>
extensions {
...
}
</pre>

This is for TRS2006 compatibility - it's all going in the extensions container. This does work in TRS2004 as well. Watch for the caveat at the end though...

====Max Permitted Speed====
<pre>
Max_Permitted_Speed-60850 "125mph"
</pre>

Not strictly part of the coupling code, but may as well mention it. This is for the Max Permitted Speed rule to tell how fast this vehicle should be permitted to travel. It will tell both AI drivers and the human driver (via the Custom HUD rule) what the maximum permitted speed is for the train they are driving, based on information from each vehicle. (And in a future version of the rule, more stuff too...)
====ACS Container====
<pre>
active-coupling-standard-60850 {
...
}
</pre>

This is the container within which all the config information will be held.

====ACS Version====
<pre>
version-major "2"
version-minor "0"
</pre>

Version numbers. This is useful when later code needs to read earlier format config files. Should make extending the standard a lot easier.

====Braking System====
<pre>
brakes "air"
</pre>

Defines what type of braking system is fitted to this vehicle. Options are:
*"air"
*"vac"
*"dual"
*"none"

This is independant of what hoses are available - unbraked but through piped stock is an entirely possible combination, and is representable.

====Position====
<pre>
front {
...
}
back {
...
}
</pre>

Containers for the front and back of the vehicle. 'Front' is defined as "the a.limfront end", and 'back' "the a.limback end". Available options for both are the same, so I'll describe them just once.
====Coupler Type====
<pre>
coupler "knuckle|screwlink|hook"
</pre>

What type of coupler do we have on this end of the vehicle? Options are:
* "hook" -- connects to screwlink/instanter/3link/hst-emergency-bar.
* "3link" -- connects to hook.
* "instanter" -- connects to hook.
* "screwlink" -- connects to hook.
* "hst-emergency-bar" -- connects to hook.
* "bar-full" -- connects to "bar-none". Half of a handed pair for when one vehicle has the entire bar coupling.
* "bar-none" -- connected to by "bar-full". The other half of the handed pair.
* "bar" -- connects to self only. Used when both vehicles have half the bar coupling.
* "knuckle" - standard knuckle coupler.
* "tightlock" -- different to a standard knuckle, refers to a knuckle style coupler often fitted to multiple unit trains that also include electrical connections.
* "wedgelock" -- London Underground coupler.
* "bsi" -- Found on Sprinter DMUs and derived designs.
* "dellner" -- Also compatible with scharfenberg coupling.
* "scharfenberg" -- Also compatible with dellner coupling.
* "(other string identifier)" -- Any string that is not recognised from the above list is assumed to be a symmetrical meet-in-the-middle type of coupler.

Certain couplers are purely compatible with other identical couplers, others are inter-compatible. Some produce handed pairs - e.g. a 3 link chain couples to a hook, and wagons with this coupling are typically fitted with both a hook and a chain.

Multiple coupler options can be specified, and are separated with a vertical bar character. The earlier option is used in preference, so list the best coupler option first.

A typical unfitted freight wagon with a 3 link coupling is specified as "3link|hook". A vehicle fitted with a knuckle, screwlink and hook (e.g. a swingknuckle fitted locomotive) is specified as "knuckle|screwlink|hook". A BR coaching stock dropknuckle (a knuckle and a hook, but no chain) is specified as "knuckle|hook". If the vehicle also has an emergency screwlink which is not permanently fitted, then "knuckle|hook|screwlink" would be appropriate -- this would cause ACS to prefer the chain type coupler from the adjacent vehicle rather than using the emergency screwlink, which would only be used when necessary. A Victorian Railways transitional coupler (which has a chain and a knuckle, but no hook) is specified as "knuckle|3link".

Dellner and Scharfenberg couplings are treated as compatible, so a dellner will also couple to a scharfenberg.

If your coupler type isn't listed, define a standard name for it, and start using it. ACS supports arbitrary extension - any new coupler it hasn't seen before will be treated as a symmetrical coupler. ACS will tell you if it has connected to an identical coupler on the adjacent vehicle.

If you need a new handed pair type (where the coupler on the end of one wagon is not the same as that on the end of another), then you will need to contact the ACS author to get one added.

====Gangways====
<pre>
gangway "gangway"
</pre>

Passenger gangway between vehicles. Options are:
*"none"
*"rubbing-plate"
*"gangway"

This is really intended for coaching stock - it is assumed that all gangways are compatible. I've been considering a 'one piece' gangway option - to aid with the centre of multiple unit trains, where there is no separation point (it will help with deciding which vehicle should display the gangway) - but I'm not sure whether this is of sufficient benefit to include, as it involves a whole new set of logic here that most people won't use, and for the cases it is interesting, the same person has made both vehicles, and can therefore do it themselves... Comments please.
====Pipes for Air Brakes====
<pre>
airbraketype "single"
airbrakeside "left"
</pre>

Brake pipes for air brakes. Options for airbraketype are:
*"twin"
*"single"
*"none"
For airbraketype, twin is the UK standard two pipe air brake system (train pipe and brake pipe). Single is the US standard air brake system where reservoirs are charged from the brake pipe rather than the train pipe (this has appeared on some modern freightcars for reasons unknown, so is included).

Options for airbrakeside are:
*"left"
*"right"
For airbrakeside, most traincars (UK, US, etc.) use left-sided airbrakes, so airbrakeside "left" will generally be used, but the right option was added to support both left and right-handed brake pipes on Australian content.

====Pipes for Vac Brakes====
<pre>
vacbrake "none"
</pre>

Brake pipes for Vacuum brakes. Options are:
*"twin"
*"single"
*"high"
*"none"

Single is the UK default for fitted stock, high connections seems to be the standard on UK steam locos. Twin pipes (operating at two different vacuum levels) has been tried in the UK - and while not much fitted stock has the twin pipe system, most air brake, through vac piped stock seems to have two vac pipes.
====Multiple Working Cables====
<pre>
multiple-working "none"
</pre>

Multiple working connections. Options are:
*"(color)-(shape)" -- e.g. "blue-star" or "red-diamond", etc
*"AAR" -- as used on GM locos
*"SR27" -- bagpipes
*"(other identifier string e.g. classname)"
====Train Heating====
<pre>
heating-type "electric"
</pre>

Coach heating. Options are:
*"none"
*"steam"
*"electric" -- standard ETH
*"dual" -- both Steam and standard ETH
*"southern-electric" -- The Southern, who pioneered electric train heating in the UK, fitted heating that was compatible with their DC powered EMUs, and thus ran from the same voltage as the DC power supply. When the rest of BR went ETH, different standards were adopted, resulting in the Southern having a different and incompatible ETH standard...

====Lighting Control Cables====
<pre>
rch "high"
</pre>

Through wiring for lighting control, to the Railway Clearing House standard. Also used more recently for other things - e.g. remote control via various methods - including TDM. I believe it is also used for signals to control doorlocks on stock so fitted - though I could be wrong on this. Options are:
*"high" -- positioned as is fairly standard on coaching stock
*"low" -- positioned as is fairly standard on streamlined locos, e.g. the front of a DVT, or a cl90
*"none"
====Notes====
For all of these where "none" is an option, entirely missing out that line is equivalent to stating "none". This should make stock which doesn't use most of the features much more palatable to produce. This will also help when extending the standard - as new features will automatically be assumed to be not present on stock built to older standards...

That's all very well and good, but how is this supposed to be backwards compatible with the old bluestar standard?

I'm making the code fall back to reading the old config entries if it can't find the new ones. The real problem is that new stock will also have to include config.txt entries for the old bluestar, so that old vehicles know what to do when they couple to this one. Yes, this means that the old tags will never actually go away, but at least TRS2006 doesn't whinge about them so hard as of SP1...

===The Script===

(under construction)

[[Category:Modeling]]

Class Str

2023-07-02T06:47:35Z

Dundun92: /* Find */

*[[TrainzScript Language Reference|API Hierarchy]]
**Str
<br>

*Str is a static class providing string utility functions not supported by the native string object.
*When used in game code these methods must be prefixed ''Str.'' to reference the class.
*Some of these methods directly amend their parameters rather than returning values via the method.
<br>

==Left==
{{MethodHeader|public void Left(string s, int count)}}
;Parameters
*'''s''' = string to be processed.
*'''count''' = count of characters to retain.
;Returned Value
*None
;Syntax
string s = "Afternoon";
Str.Left(s,5); // s will now be equal to "After"
;Notes
*Sets ''s'' to be a substring of itself consisting of its first ''count'' characters.
*Method does not return a value.
<br>

==Mid==
{{MethodHeader|public void Mid(string s, int first, int count)}}
;Parameters
*'''s''' = string to be processed.
*'''first''' = index of first character to retain.
*'''count''' = number of characters to retain.
;Returned Value
*None
;Syntax
string s = "Afternoon";
Str.Mid(s,3,4); // s will now be equal to "tern"
;Notes
*Sets ''s'' to be a substring of itself ''count'' characters long starting with the ''first'' character.
*Method does not return a value.
<br>
<I>To get the output specified you would need the following: Str.Mid(s,2,4); as the string array is zero based. This has been tested using TS2012 build 61388 and TANE. </I>
<br>

==Right==
{{MethodHeader|public void Right(string s, int count)}}
;Parameters
*'''s''' = string to be processed.
*'''count''' = number of characters to retain.
;Returned Value
*None
;Syntax
string s = "Afternoon";
Str.Right(s,4); // s will now be equal to "noon"
;Notes
*Sets ''s'' to be a substring of itself composed of the last ''count'' characters.
*Method does not return a value.
<br>

==Find==
{{MethodHeader|Find(string s, string substr, int startingIndex)}}
;Parameters
*'''s''' = string in which to search
*'''substr''' - substring to find
*'''startingIndex''' - where to start looking down the string i.e. skip the first 'n' characters
;Returned Value
*index within string that substr starts at. '-1' if not found.
;Syntax
int i = Str.Find("z", "amazon", 0) //returns 4
;Notes
*Searches for a substring within a string.
<br>

==ToInt==
{{MethodHeader|public native int ToInt(string s)}}
;Parameters
*'''s''' = string parameter, which should be a string representation of an integer.
;Returned Value
*Integer value of string parameter.
;Syntax
int n = Str.ToInt("1234");
;Notes
*Converts ''s'' to an integer.
*Method returns 0 if the string cannot be converted.
<br>

==ToFloat==
{{MethodHeader|public native float ToFloat(string s)}}
;Parameters
*'''s''' = string parameter, which should be a string representation of a floating point number.
;Returned Value
*Floating point value.
;Syntax
float length = Str.ToFloat("1.5");
;Notes
*Converts ''s'' to a floating point number.
*Method returns 0.0 if the string cannot be converted.
<br>

==Tokens==
{{MethodHeader|public native string[ ] Tokens(string s, string delimiters)}}
;Parameters
*'''s''' = string to be processed.
*'''delimiters''' = string of characters to use as token boundaries.
;Returned Value
*Array of string tokens.
;Syntax
string[] sentence = Str.Tokens("Once upon a time",""); // sentence contains an array of four strings:
// ["Once","upon","a","time"].
int wordCount = Str.Tokens("Once upon a time","").size(); // returns 4
string firstWord = Str.Tokens("Once upon a time","")[0]; // returns "Once"

string kuidStr = "<kuid:1234:5678>"
string userID = Str.Tokens(kuidStr,"<:>")[1]; // returns "1234"
;Notes
*Splits a string into an array of tokens using any of the characters in ''delimiters'' as token boundaries.
*Characters contained within the ''delimiters'' string are never returned.
*If ''delimiters'' is null or an empty string then white space will be assumed to define the token boundaries.
<br>

==ToLower==
{{MethodHeader|public native void ToLower(string s)}}
;Parameters
*'''s''' = string to be processed.
;Returned Value
*None
;Syntax
Str.ToLower("UPPER CASE STRING");
;Notes
*Converts the string parameter ''s'' to lower case.
*Method does not return a value.
<br>

==ToUpper==
{{MethodHeader|public native void ToUpper(string s)}}
;Parameters
*'''s''' = string to be processed.
;Returned Value
*None
;Syntax
Str.ToUpper("lower case string");
;Notes
*Converts the string parameter ''s'' to upper case.
*Method does not return a value.
<br>

==TrimLeft==
{{MethodHeader|public native void TrimLeft(string s, string trim)}}
;Parameters
*'''s''' = string to be processed.
*'''trim''' = characters to remove
;Returned Value
*None
;Syntax
Str.TrimLeft("Once upon a time","Once "); // returns "upon a time"
Str.TrimLeft(" result",""); // returns "result"
;Notes
*If ''trim'' is an empty string then all white space will be stripped from the front of the string.
*Method does not return a value.
<br>

==TrimRight==
{{MethodHeader|public native void TrimRight(string s, string trim)}}
;Parameters
*'''s''' = string to be processed.
*'''trim''' = characters to remove
;Returned Value
*None
;Syntax
Str.TrimRight("Once upon a time"," a time"); // returns "Once upon"
Str.TrimRight("result ",""); // returns "result
;Notes
*If ''trim'' is an empty string then all white space will be stripped from the end of the string.
*Method does not return a value.
<br>

==UnpackInt==
{{MethodHeader|public native int UnpackInt(string s)}}
;Parameters
*'''s''' = string to be processed.
;Returned Value
*First integer value in ''s''.
;Syntax
int n = Str.UnpackInt("21st May 2008"); // returns 21 and amends ''s'' to "st May 2008"
;Notes
*Strips the first integer value found from the string parameter and returns it in the method result.
<br>

==UnpackFloat==
{{MethodHeader|public native float UnpackFloat(string s)}}
;Parameters
*'''s''' = string to be processed.
;Returned Value
*First float value in ''s''.
;Syntax
float distance = Str.UnpackFloat("21.5 miles"); // returns 21.5 and amends ''s'' to " miles".
;Notes
*Strips the first floating point value found from the string parameter and returns it in the method result.
<br>

==UnpackString==
{{MethodHeader|public native string UnpackString(string s)}}
;Parameters
*'''s''' = string to be processed.
;Returned Value
*First string in ''s'', excluding any leading white space.
;Syntax
string s = "Once upon a time";
string firstWord = UnpackString(s); // returns "Once", s becomes " upon a time"
string secondWord = UnpackString(s); // returns "upon", s becomes " a time"
string thirdWord = UnpackString(s); // returns "a", s becomes " time"
string fourthWord = UnpackString(s); // returns "time", s becomes ""
;Notes
*Strips the first word from the string parameter (using white space for word separation) and returns it in the method result.
*Any leading white space is removed from the string before parsing.
<br>

==CloneString==
{{MethodHeader|public string CloneString(string s)}}
;Parameters
*'''s''' = The string to clone.
;Returned Value
*string - A new string in the current gamescript context which has contents that exactly match the original string.
;Syntax
string original="Hello World!"
string copy;
copy=Str.CloneString(original);
;Notes
*CloneString() creates a copy of the string passed.
*Ordinarily 'copying' a string will just create a new object that references the old string. This is not allowed across different contexts.
*CloneString() creates a new string for use in the current context.

==Related Methods==

[[Class TrainUtil#AlreadyThereStr|TrainUtil.AlreadyThereStr()]]

[[Class TrainUtil#CompareStrLists|TrainUtil.CompareStrLists()]]

[[Class TrainUtil#GetUpTo|TrainUtil.GetUpTo()]]

[[Class TrainUtil#HasPrefix|TrainUtil.HasPrefix()]]

[[Class TrainUtil#HasSufix|TrainUtil.HasSufix()]] ''(sic)''

[[Class TrainUtil#StrSubst|TrainUtil.StrSubst()]]

==Categories==
[[Category:Script Class]]

Help:VE170

2023-05-18T18:00:15Z

Dundun92:

Failed to open compiled texture ''texture-name'' for ''archive-file-name''

This is a general failure error for texture files. It is usually one of two or more messages related to a failure to process a texture file - the other errors provide a more precise description of the problem.

For example:
- VE170: Failed to open compiled texture 'coal_3.texture' for 'arc:fld:$(local)/hash-2D||kuid2 1234 5678 2.tzarc|'

In this particular case the texture file was missing - the missing file was reported as error [[Help:VE165|VE165]].

If VE170 is reported as the only error, it probably indicates a letter in the texture file is uppercase. For example, Coal_3B.texture should be coal_3b.texture. Also, make sure you are using forward slashes when referencing folders. Otherwise, it is likely an internal processing error.
[[Category:Validation Errors]]

Help:VE220

2023-05-08T05:50:28Z

Dundun92:

This could mean the declared functions return type is different from the actual function.

void GetSpeed(bool dir);

int GetSpeed(bool dir)
{

}

The declared function is void, but the actual function is int;

It could also mean you have the same function declared twice with different parameters:

int DetermineCarPosition(void);
void SetTwoDigitCode(string code);
'''void SetDestination(string code);'''
void SetTexture(int index);
void SetAttachment(int side, int middle, int high, int highbeam);
'''void SetDestination(int index, int code);'''

Help:VE220

2023-05-08T05:50:17Z

Dundun92:

Help:VE220

Dundun92: /* Blender Material Configuration (2.8+) */

[[m.pbrmetal]] is the most basic PBR-based material type used in Trainz, and should be the default material type of choice for any mesh unless some specific feature of some other material type is required. All PBR materials are defined using a multitude of texture channels (not just a simple RGB image) which define various aspects of the material on a per-texel basis. One major advantage of this approach is that a single in-game [[material]] can be used to display various different real-world materials, rather than requiring multiple separate in-game materials with different parameters. Trainz uses a Metallic/Roughness style [[Physically Based Rendering|PBR workflow]].

It should be noted that the "metal" in the name of this material refers to the physical property used in the lighting equations; it does not mean that the material is only appropriate for metallic surfaces.

This page describes [["Trainz-build" number|content format v4.6]] and assumes that the [[FBX file format]] is used as a data source for any meshes.

=Texture Slots=
The following texture slots are used for this material. All textures should typically have the same dimensions unless they represent a uniform color, however this is not strictly enforced.

==Albedo==
RGB: The [[albedo map]] defines the base color of each texel. The sRGB color space is used.

Please note that there is no alpha channel support. For the most robust result, the alpha channel should be omitted or set to 1.0 (white). Note that unlike legacy Trainz materials, PBR materials do not autodetect opacity mode based on the texture in use. The content creator must select the appropriate material for their desired outcome. Runtime texture replacement should not expect to replace an opaque texture with a blended or masked texture and have the material update automatically.

'''Albedo Texture Example'''

[[File:pbralbedomap1.jpg|border|middle|x200px]]

==Normal==
RGB: Surface [[normal map]]. This defines which way the surface is facing, relative to the interpolated vertex normals. Since this is an XYZ format rather than color data, it should never be modified in Photoshop. Using Photoshop to add a fourth channel or copy/paste smaller textures into a [[texture atlas]] is acceptable. Per-pixel manipulation or use of filters on the "RGB" channels is not acceptable.

A: [[Parallax Occlusion Map|Displacement height]]. 0.0 represents the deepest possible value, while 1.0 represents the shallowest possible value. While it is possible to paint this data in Photoshop, a linear color space must be used, and far superior results will be available through other data sources. The parallax height and the surface normal must be kept in sync, which means that a third-party tool must be used to generate the surface normal from the parallax height if you are painting this map manually.

'''Normal Texture Example with no Alpha Channel (Parallax)'''

[[File:pbrnormalmap1.jpg|border|middle|x200px]]

'''Normal Texture Example with Alpha Channel (Parallax)'''

[[File:pbrnormalwithalpha.jpg|border|middle|x200px]]

==Parameter==
This texture is comprised of four separate channels which each form a separate data element. Linear color space (not sRGB) is used for these channels.

[[File:pbrparametersall.jpg|border|middle|x200px]]

*'''Parameters (Emissive - Red Channel) Texture Example'''

:[[File:pbrparametersemissivemap1.jpg|border|middle|x200px]]

:R: Emissive. This causes the texture to have an internal glow, even when no external light is present. Used for phosphors, permanently-lit markings, etc. The glow color is based on the albedo. Note that this glow does not cast light upon surrounding surfaces except via the Bloom post-processing effect. You might want to consider making this a gray / dark gray color on some assets that you want more of the albedo color to show through indirect (ambient) lit surfaces.

*'''Parameters (Roughness - Green Channel) Texture Example'''

:[[File:pbrparametersroughnessmap1.jpg|border|middle|x200px]]

:G: Roughness. Defines whether the surface reflections are shiny (0.0) or matte (1.0). See the [[Physically Based Rendering|PBR metal workflow]] for details.

*'''Parameters (Ambient Occlusion - Blue Channel) Texture Example'''

:[[File:pbrparametersambientocclusionmap1.jpg|border|middle|x200px]]

:B: Ambient Occlusion. Defines whether the surface is exposed to ambient lighting conditions (1.0) or affected only by direct lighting (0.0).

*'''Parameters (Metallic - Alpha Channel) Texture Example'''

:[[File:pbrparametersmetallicmap1.jpg|border|middle|x200px]]

:A: Metallicity. Defines whether the surface is metallic (1.0) with the albedo used to colorize reflected light, or dielectric (0.0) with the albedo used to colorize the surface. While intermediate values are not physically accurate, they may be used to emulate subsurfaces which are partially metallic. See the [[Physically Based Rendering|PBR metal workflow]] for details.

=Examples=
The following images show this material type with a few basic configurations of roughness and metallicity, under identical environmental conditions.

[[File:m.pbrmetal-0.png|border|middle|x200px]] [[File:m.pbrmetal-1.png|border|middle|x200px]] [[File:m.pbrmetal-2.png|border|middle|x200px]] [[File:m.pbrmetal-3.png|border|middle|x200px]]

[[File:trainz_material_cast_iron.jpg|border|middle|x512px]]

Example asset download:

[http://download.trainzportal.com/tutorials/Trainz_Material_-_pbrmetal_(cast_iron).cdp Trainz Material - pbrmetal (cast iron)]

[[File:trainz_material_gloss_paint.jpg|border|middle|x512px]]

Example asset download:

[http://download.trainzportal.com/tutorials/Trainz_Material_-_pbrmetal_(gloss_paint).cdp Trainz Material - pbrmetal (gloss paint)]

[[File:trainz_material_painted_metal.jpg|border|middle|x512px]]

Example asset download:

[http://download.trainzportal.com/tutorials/Trainz_Material_-_pbrmetal_(painted_metal).cdp Trainz Material - pbrmetal (painted metal)]

[[File:trainz_material_rubber.jpg|border|middle|x512px]]

Example asset download:

[http://download.trainzportal.com/tutorials/Trainz_Material_-_pbrmetal_(rubber).cdp Trainz Material - pbrmetal (rubber)]

[[File:trainz_material_stainless_steel.jpg|border|middle|x512px]]

Example asset download:

[http://download.trainzportal.com/tutorials/Trainz_Material_-_pbrmetal_(stainless_steel).cdp Trainz Material - pbrmetal (stainless steel)]

[[File:chart_roughness_metallic.jpg|border|middle|x512px]]

Example asset (route + objects) download:

[http://download.trainzportal.com/tutorials/pbr_roughness_metallic_chart_180831a.cdp PBR Roughness / Metallic Chart]

=3ds Max Material Configuration=

'''Texture Assignment'''

[[File:pbrmetal3dsmaxtextureassignment.jpg]]

=Blender Material Configuration V2.79b=

You must use the Blender Render option in Blender as the Cycles Render in V2.79b doesn't export the texture names associated with the material.

The albedo and normal textures have no special requirements but the parameters texture must use the Influence->Specular->Hardness tag (checkbox). The value of the hardness is not exported by the Blender FBX exporter. Sample settings are shown below. Note that the normal texture does not use an alpha channel in this example.

[[File:Blender_PBRMetal_albedo_setting.jpg|border|middle|x700px]] [[File:Blender_PBRMetal_normal_setting.jpg|border|middle|x700px]] [[File:Blender_PBRMetal_parameters_setting.jpg|border|middle|x700px]]

=Blender Material Configuration (2.8+)=

The shader node is a Principled BSDF shader and the FBX exporter supports the export of some texture names but not all. The following connections should be made:

Albedo texture to the Base Color input.

Parameter texture to the Roughness input.

The normal texture, via a normal converter set to Tangent, to the Normal input.

The 3D view of the mesh does not show a true PBR render.

You will need to update the texture.txt files created by the Trainz FBX importer.

[[File:MpbrmetalExportBlender2.8beyond.png|border|middle|x600px]]

=Maya LT Material Configuration=

Maya LT uses a Phong shader and the parameters texture should be linked to the shader Cosine Power input via a Set Range node. Note that the input and output of this node both use Value X. The Normal Map must be passed through a Bump converter and then connected to the shader Normal input. The Bump converter "Use as" value within the attributes editor must use the "Tangent Space Normals" option. See the images below.

''Note. The material name shown in these images has "FBXASC046" where the full stops (periods) appear in the name box.m.pbrmetal. Maya LT does not permit full stops (periods) in name and substitutes an underscore which doesn't work for Trainz. FBXASC046 gets replaced with a full stop on export. N3V are looking at this issue.''

[[File:Sample_pbrmetal_material.jpg|border|middle]]
[[File:Sample_pbrmetal_material_properties.jpg|border|middle]] [[File:Bump_normal_converter_properties.jpg|border|middle]]

=Substance Painter Export Preset=

Export preset for Substance Painter. This preset puts every map you need into Albedo, Normal and Parameter texture channels. As result you will get 3 textures, ready for importing into game.

The link below is a preset that has height maps enabled by default.

[https://www.dropbox.com/s/ukp3p8uw53332ay/Trainz2019_WithHeight.spexp?dl=0 Trainz 2019 Exporter with Height Maps Enabled]

The link below contains a preset that does not have height maps enabled, which may be more useful to some on rollingstock.

[https://www.dropbox.com/s/4gzmuzdy8g7nwzc/Trainz2019.spexp?dl=0 Trainz 2019 Exporter with Height Maps Disabled]

==Installing the Preset==

First download either or both presets to your computer from the links above. Open Substance Painter and navigate to File -> Import Resources.

[[File:Step2.png]]

At the top of the new window, click on "Add resources." Then locate your preset you'd like to import.

[[File:Step3.png]]

After selecting the preset Substance Painter should already recognize that it is an export preset.

[[File:Step4.png]]

In the dropdown window at the bottom right corner of the active window, you can select where you want to save it. You can either save this into your project file you are currently working on, or add it to your shelf. If you save it to your shelf you won't have to import it for every project, so this is the best method! After you are done, click Import.

[[File:Step5N.png]]

==Exporting Textures==

When you are ready to export your textures from your project, navigate at the top left to File -> Export Textures.

[[File:Step6.png]]

In this new window, select the dropdown window near "Config" and select your Trainz 2019 preset from the dropdown window. After you select which texture size you want to export or which materials to export, hit export and your textures will export! At the top of the window will be the directory where your textures will export to. In my case, it is exporting to K:\Class 47\Textures\game\lit up. You can change the directory by simply clicking on it.

[[File:Step7.png]]

That's all you have to do! These presets will support all PBR materials including pbrmetalmasked, and glass. However to use alphas you will need to enable opacity in the Texture Set Settings.

[[Category:Material types| ]]
[[Category:Modeling]]
[[Category:Content creation]]

File:MpbrmetalExportBlender2.8beyond.png

2023-02-16T00:35:19Z

Dundun92: The proper shader configuration for m.pbrmetal textures in Blender (2.8+)

The proper shader configuration for m.pbrmetal textures in Blender (2.8+)