Texture-Replacement Effect

The Texture-Replacement effect kind is a named effect container within a "mesh-table" Container. It can be used within the load subcontainer to provide alternative textures for bulk loads in wagons. The following tags are supported:

Supported Tags

Each texture-replacement subcontainer supports the following tags.

kind "texture-replacement"
texture "<texture name>"

The name of the texture-replacement effects subcontainer is selected by the content developer. It may be used as a reference in a script file to identify a specific effect.

kind

String. Required. No default. "texture-replacement"

texture

String. Required. No default. The name of the texture that is to be replaced. This is the name of the texture file as used in the asset's config.txt, without the .txt extension. For instance, if the texture to be replaced is identified in the 'load-map.texture.txt' file, then the texture tag in the effect container is "load-map.texture".

A texture-replacement effect is often used when the texture of an asset should be changed during game play. For instance, when the load texture is to be replaced then this texture will be replaced by the texture contained in the product referenced in the current active product queue, as defined by the allowed-categories subcontainer in the queue. For instance, if a coal hopper loads at an industry asset that produces a bulk-load other than its default load (eg woodchips at a lumbermill), then the woodchip product texture will replace the default coal product texture.

A texture-replacement effect is also used when an asset is reskinned using an alias. In this case the texture replacement occurs when the asset is created - the texture of the aliased asset is replaced with a texture from the reskin asset.

Example texture-replace subcontainer

   effects {
     product-texture {
       kind      "texture-replacement"
       texture	  "load_map.texture"
     }
   }

Performance Considerations

Texture-replacement can be used by content developers to achieve a range of interesting and novel scripted effects, though there are some considerations that should be noted. Whether performance will be adversely affected is dependant upon numerous variables. When it comes to predicting the performance impact of a particular texture-replacement implementation, the only reliable answer is: test it and see.

potential issues

• it's likely to load both the original and the replacement textures, so you may pay twice the loading cost and twice the RAM cost.

• in older versions of the game, you might end up with the game freezing while it loads in the replacement texture.

• in newer versions of the game, it shouldn't freeze but it's feasible that you might end up with the old textures visible on screen until the new textures load.

• it likely negates any texture preloading, so you're more likely to end up with low-res textures visible to the user.

• it likely disables a bunch of shared-material optimisations, so if you have multiple copies of the same object around then you'll now be paying one cost per instance rather than one cost per the whole set.

In newer versions some of that can be mitigated:

• as long as all of the textures look fairly similar, swapping from one to another once already visible isn't a major concern as long as it happens at lower LODs, which it generally will during actual game play.

• texture streaming makes it more likely that the double-texture costs will be minimal. You can probably further assist this by using smaller placeholder textures to start with i.e. the textures loaded as part of the mesh are kept to 32x32 or something small like that.