Newbie here, trying to add multiple custom ground textures

rgarber

New member
Regarding adding ground textures to the Config.txt file. I found a discussion explaining how to add one ground texture to a route but I have several I'd like to add. I've made the custom text files for each texture and now I'm ready to do the Confix.txt file. A couple of questions: Are all the custom ground textures added to the same Config.txt file or does each texture (ground) get it's own config file? And does someone have an example on how the config.txt file is suppose to be setup with the multiple textures? Oh, and where in the route's folder does the config(s) file(s) go too? Thanks! - Rich
 
Hi Rich,

All assets, regardless of the kind, get added to the route or session config.txt file automatically. There is no need to edit this except on rare occasions for other purposes.

I recommend that you clone a texture from another creator then simply replace the parts with your own.

To clone an asset:

Start up Content Manager (Manage Content on the Launcher).

Download or search in your installed assets for textures. You can't edit a payware texture, and built-ins will give you another error, but you can edit and modify those you installed from the Download Station (DLS) and installed manually. You can customize the search for category texture, and there are two kinds; environmental and not-environmental. I don't know which ones you want. Here is a texture I created from an asset. It's not the best, but you can download this one from the DLS. Look for Bati Quarry Rock. Keep in mind that it's older, but it contains the elements you need.

Code:
trainz-build                            2.9
username                                "Bati Quarry Rock"
kind                                    "groundtexture"
texture                                 "groundtexture.texture"
normal-texture                          "groundtexture_normal.texture"
category-class                          "GL"


thumbnails
{
  0
  {
    image                               "Bati Quarry Texture.bmp"
    width                               240
    height                              180
  }
}
kuid                                    <kuid:124863:1014>
description                             "A texture copied from the Bati Quarry originally created by Raymond Parrot and now a built-in item. The texture was created because I wanted to blend in the quarry with the rest of the terrain. The texture is uploaded as-is, and no warranties or guarantees are expressed or implied."

== To clone an asset, click on the one you want to clone, and press CTRL-D.

This will duplicate the asset.

== Change the view to Open for edit.

You will see something called New Asset.

== Verify this is the asset by checking the install date. (You might need to add the column in CM. To do so, right-click on the columns and add that in. You might have to resize the columns to fit your screen). The date should be the current date.

== Right-click on the "New Asset", and choose Open in Explorer.

This will open a Windows File Explorer window showing the innards of the asset.

== Replace the textures with your own.

== Edit the texture-name.texture.txt.

In your editor, Notepad, or Notepad++ for example, you need to change the referenced texture files.

== Rename the .texture.txt to be exactly the same as your texture file using the format shown.

Code:
 Example texture_name.texture.txt

Primary=groundtexture.tga
Alpha=groundtexture.tga
Tile=st

The file is also called groundtexture.texture.txt (I know I'm boring!).

== Save the texture.txt

== Edit the config.txt file and change the details such as Username, which is the texture name, author, etc., to suit including the name of the referenced texture. You MUSTkeep the formatting including the quotes.

== Save and close when done.

== Close the Windows File Explorer window.

== Submit the asset - right-click and choose Submit (I never remember the short-key for this).

== Check faulty assets. If your asset shows up with an error, check your work. Look for the usual things like typos, and ensure all the references are correct. Other texture errors can occur. For .TGA files, they can't be RLE compressed. JPGs don't work well for some reason so stick with TGA format for now.

Hope this helps.

For further reference for other options, tweaks, and good information on this, I recommend checking the Wiki http://online.ts2009.com/mediaWiki/index.php/KIND_Texture
 
Hi Rich,

All assets, regardless of the kind, get added to the route or session config.txt file automatically. There is no need to edit this except on rare occasions for other purposes.

I recommend that you clone a texture from another creator then simply replace the parts with your own.

...

Hope this helps.

For further reference for other options, tweaks, and good information on this, I recommend checking the Wiki http://online.ts2009.com/mediaWiki/index.php/KIND_Texture

Thanks John for all that information. So if I could summarize what you're saying is the best way for me to put my own ground textures into my route, or assets, is to download somebody else's texture/asset into the game, edit to reflect my own texture/asset, submit it and then I have folder entry in the directory Editing which is now my own ground texture. And I can see it has my own KUID.

But how does that ground texture end up selectable in my route project if it's in a folder off on its own? Thanks again. Very new at this. - Rich
 
But how does that ground texture end up selectable in my route project if it's in a folder off on its own?
If you have it set up with the required files and config in a folder then the next thing to do is to import that folder using Content Manager: File \ Import Content Folder. The asset will then appear in Content Manager and in the 'Paint' tab in Surveyor, ready for painting onto your route baseboards. Check carefully that it was imported into Content Manager with no errors.
 
If you have it set up with the required files and config in a folder then the next thing to do is to import that folder using Content Manager: File \ Import Content Folder. The asset will then appear in Content Manager and in the 'Paint' tab in Surveyor, ready for painting onto your route baseboards. Check carefully that it was imported into Content Manager with no errors.

Thanks for taking the time to explain that. Much appreciated! - Rich
 
Success! But still some questions

trainz_gnd_texture.jpg
Took awhile but I got my test texture into Trainz.

http://www.allaboardrails.com/trainz_gnd_texture.jpg
trainz_gnd_texture.jpg

trainz_gnd_texture.jpg


Can you not load images directly into this forum? I had to upload this one to my site and I can't get the picture to show but the link is right.

Anyway, the question I have is with the way the normal is handled. So the example had the normal reference in the Config.txt pointed to a text file (instead of the normal graphic itself). And in the example I'm guessing there wasn't a real normal used so the main texture BMP was used instead like a placeholder. But if I was using a real normal map, the normal.txt file should point to the normal texture? And where my confusion is, why if we're referencing the normal in the config.txt file why is the normal.txt file even necessary? Why not just reference the actual normal in the Config.txt file instead? Thanks for all your help, btw.

For keeping the game running smoothly do you'all keep your normals at the same texture height and width as the texture itself? I think I saw someone in a video on youtube say something about cutting the normal in half. Is that right?

Rich
 
Last edited:
Can you not load images directly into this forum?

You can insert an image by placing it on a site as you have, then select Go Advanced below your message and you will get an insert image icon. Paste the URL of the image into that.

Each reference to an image from a config file should be to a texture.txt file. There are some exceptions (for historical reasons) but I don't think ground texture is one of them. When using the wiki it is often useful to review the history of a page to see how the requirements for a particular asset have changed over the different versions. The texture.txt file contains information about the image for the texture, including the image file name.
http://online.ts2009.com/mediaWiki/index.php/Texture_file

This information includes a tag to identify the normal map as a normal map and not an image. The tag used in the config ought to be sufficient, but there are historical reasons for doing it in both places. If you do this using AssetX then the process is much simplified. The reference above might explain how your template is configured, but reusing the primary image as a normal map sure doesn't sound right. Much better to have them completely separate.

There are a series of rules about how image size needs to be configured. I can't think of any reason for doing the normal map at anything other than the same size as the main image file. All this information is converted to an internal format when the asset is submitted, so there could be several different ways to achieve the same result. Also, there is a lot of out-of-date information provided in the video tutorials.
 
Using the primary image as the normal map was quite "normal" back in the build 2.9 days. As I said, check the wiki for more updated information. I'm sorry I provided obsolete information, but Trainz is a pit of it due to backwards compatibility abounding everywhere.

With that said, I'll keep my mouth shut from now on and let the experts spout on about how to do stuff.
 
Each reference to an image from a config file should be to a texture.txt file. (a)

This information includes a tag to identify the normal map as a normal map and not an image. The tag used in the config ought to be sufficient, but there are historical reasons for doing it in both places. If you do this using AssetX then the process is much simplified. (b)

There are a series of rules about how image size needs to be configured. I can't think of any reason for doing the normal map at anything other than the same size as the main image file. All this information is converted to an internal format when the asset is submitted, so there could be several different ways to achieve the same result. Also, there is a lot of out-of-date information provided in the video tutorials. (c)

(a) Thanks! That explains some of the confusion. I do like getting things done but I also, sometimes, like to understand why I'm doing things and not leave everything up to rote.

(b) I would like to comment on the seemingly CSS style of the way Trainz is coming across to me but more importantly, since I like easy, what is AssetX? If it helps with adding assets into Trainz I am all for learning it.

(c) And thanks again. The question I really want to ask but first thought it was better to understand how normals are handled in Trainz is Normals with ground textures? I'm all for better graphics but adding all that information especially where ground is concerned (like it's all over the place) is it even practical? Sounds like a frame rate killing machine to add normals to the terrain. So as a newbie, what's your opinion on normals with ground textures. Anyone really. Like a question I would have, would somebody be able to see the effect of normals from the cab? Or do you have to get to ground level to see the effects?

- Rich
 
Using the primary image as the normal map was quite "normal" back in the build 2.9 days. As I said, check the wiki for more updated information. I'm sorry I provided obsolete information, but Trainz is a pit of it due to backwards compatibility abounding everywhere.

With that said, I'll keep my mouth shut from now on and let the experts spout on about how to do stuff.

No need, you're fine by me. I was looking for answers in the forum because I couldn't make sense of the information I was getting from elsewhere. Wiki's are fine for schematic-like how-to's but they often don't include the personal touch of what to emphasize first for someone just starting out. I got my test texture into Trainz because of what you wrote. It took me a couple of days to work through your tutorial and it took doing it and failing a couple of times to realize the pitfalls when adding assets. I find the behavior of this process odd to be honest. Like for instance, once the asset is submitted the whole folder disappears. I luckily had a backup of that folder or I would've panicked. But I then learned if I reopened the asset for edit the folder reappears. Of all the games I've done route building in this is the weirdest. I get it that once I am more experienced with the process it will be fine. But for now, I'm stuck on the idea that I got to download that same ground texture asset every time I want to add a new asset.

You answered my post by writing a fairly complete tutorial. So I thank you. That's a lot of work you did for somebody you don't know. Much appreciated. :D - Rich
 
Last edited:
AssetX is an extremely useful program for fixing, updating even creating assets as in config.txt. It was created by the late andi06 and pev. It was full integrated with Trainz up to TANE, As we lost Andi years before his time it hasn't been updated yet, Andi was the main coder. However it's useable in the newer versions by setting up the TRS19 editing folder as a home folder which will populate AssetX with whatever is in the editing folder after starting it.

It's available from Shane Turners site, along with other useful stuff from Pev here http://trainz.shaneturner.co.uk/tutorials/index.php/home/utilities/pevsoft-trainz-tools.

Images2TGA is handy as you can have a look at other ground texture tga files to see how the alphas are used for the actual texture and the normals you can also add alphas and create a basic normal with it.

I use a white alpha for the image and black for the normal, changing the normals alpha to a grey shade causes a shiny effect.

PBR textures however are a whole different ball game, still trying to fathom PBR out myself!
 
No need, your fine by me. I was looking for answers in the forum because I couldn't make sense of the information I was getting from elsewhere. Wiki's are fine for schematic-like how-to's but they often don't include the personal touch of what to emphasize first for someone just starting out. I got my test texture into Trainz because of what you wrote. It took me a couple of days to work through your long post and it took doing it and failing a couple of times to realize the pitfalls when adding assets. I find the behavior of this process odd to be honest. Like for instance, one that asset is submitted the whole folder disappears. I luckily had a backup of that folder or I would've panicked. But I then learned if I reopened the asset for edit the folder reappears. Of all the games I've done route building in this is the weirdest. I get it that once I am more experienced with the process it will be fine. But for now, I'm stuck on the idea that I got to download that same ground texture asset every time I want to add a new asset.

You answered my post by writing a fairly complete tutorial. So I thank you. That's a lot of work you did for somebody you don't know. Much appreciated. :D - Rich

I'm glad I was helpful. :D

I'll clarify something here for you, and give you a bit more stuff to chew on. :)

Once an asset is installed, it becomes part of your installed assets that you can use on other projects. There is no need then to download the same assets again and again unless there's an update to the assets. If an update has been installed, the previous version is automatically obsoleted and can be deleted if it's not built-in or payware (DLC)

Trainz is setup this way with all installed assets, regardless of their type. The assets go into folders, but can't be edited in their raw form and need to be accessed through content manager because they are referenced through a database - yes an actual MySql database which has a proprietary front end that's only accessible from within the program either through Trainz its self, or via content manager. When an asset is submitted, it's compressed down to a much smaller size and a pointer is made in the the assets.tdx file for reference within the program.

It wasn't always this way. In Trainz versions prior to TRS2006, we're talking ca. 2005 now, all the assets were installed uncompressed into a World/Data folder or something like that. This made our life easier in someways, but it was very slow loading content because nothing was indexed, and cache files had to be deleted and rebuilt manually every time a change was made. With the improvements over time, the database form became more refined and with TS12 came a daemon to allow multiple access points to the data, which is how it is today. By this I mean you can run TRS19 at the same time while accessing content in Content Manager. Up until that TADDaemon was introduced, creating content and viewing it once submitted was a one or the other and Trainz had to be closed while Content Manager was in operation. This setup we have now also allows us to download and install content and query in Content Manager while running Trainz in another window.

Another thing that came about just prior to TRS2004 where I started this journey myself is the KUID system, which is essentially a bar code system that allows a unique key to represent assets that are installed. The KUID system works like this:

The original KUID system:
<kuid : User-ID : Asset ID>

This system required an obsolete-table within the config.txt that holds an obsoleted asset that the current one is replacing. This had its issues with asset kuids erroneously replacing another asset as well as other issues. To make things a bit simpler and to allow more flexibility, the newer KUID 2 system was developed which allows versions of assets instead of referencing within the config.txt.

<kuid2 : User-ID : Asset ID: Version>

With the new system, updating the version number from 1 to 2 for example, will automatically obsolete the previous version. There is a possibility of 127 (0 inclusive) possible iterations of assets, but never use a version of 127, otherwise, there's a roll over to zero!

As you'll find out, there's a lot more to this program than meets the eye. With about 20 years of development, it's become quite complex. Please feel free to ask questions. There's a lot of knowledge floating around here in the forums, but sometimes it's easier to ask for fresh advice.
 
....

Once an asset is installed, it becomes part of your installed assets that you can use on other projects. There is no need then to download the same assets again and again unless there's an update to the assets.

Thanks John, the history explanation helped if only to stop grumbling beneath my breath who created this crazy system and why. I'm getting quicker with it being able to, like you say add new content without having to re-download the quarry ground texture.

I'm still having a couple of issues thus far I could use some help on. First, what's the deal with the Build #. I'm taking some hits on it no matter what I use. If I use the 2.9 in the original quarry file the error message says builds below 3.5 are no longer supported. But if I use my current train build which says 100240 then the game calls me a liar and says no such build exists. What is the correct build this maniacal 'thing' is looking for?

Also, my thumbnails are not showing. The game must be making its own version of thumbnails for me but I made some custom-built thumbnails (240 x 180) and using the BMP protocol. Mine don't show. I am getting an error 62, something about something isn't where its suppose to be but I can't figure out what it's referring to. My guess is that it must have something to do with the thumbnail since mine isn't showing

Here's a quick pic of my textures, they are working but I have a question about this too...



Is there a way to blend the ground textures? Seems like the texture hits the ground at the same intensity -- like there's no light touch to ease the texture like say on another texture to get a smoother blend.

Rich
 
Is there a way to blend the ground textures? Seems like the texture hits the ground at the same intensity -- like there's no light touch to ease the texture like say on another texture to get a smoother blend.
History is also important for individual asset types. For instance, ground textures suffered a major revision in 2017. If you look at the 2016 version of the wiki entry for kind groundtexture you get the configuration as at about build 3.7. That is a very useful build number for this particular asset, as it uses a much simpler texture structure with very good bump effects. If you build to this version note carefully how the alpha channel of the normal map is used - a lot of textures got this wrong and showed excessive reflection when viewed against the sun.

You can 'ease' the texture using transparency, assuming the user understands that the texture is designed to be used as an overlay and not as a base texture, but there is nothing that automatically produces a blending. The best solution is to provide several similar textures that can be used to create a more gradual transition: for instance, lush green grass, brownish grass, and ballast with a bit of grass. The effect is achieved by careful selection and application during route building, not by any specific feature you can build into the textures themselves.
 
Hi Rich,

Your textures look great! You can blend textures into each other by moving your mouse faster over the area you are texturing. You can also rotate textures too by using the square brackets ([,]) keys. This isn't recommended for photo-realistic textures such as highly detailed rock textures, but it works well for grass, gravel, sand, and even your textures I think.

Use JPG for your thumbnails instead of BMP. Put the thumbnail file into the asset folder and then edit the config.txt file to ensure that your actual file name is being referred to and not a previous one. The thumbnail needs to be referenced in the config.txt file in the thumbnails container.

Code:
thumbnails{
  0
  {
    image                               [B]"thumbnail.jpg"[/B]
    width                               240
    height                              180
  }
}

Are you receiving an actual error on the build number, or is it a warning? The faulty asset would be faulty and red when submitted, and the error message would have a red X icon next to the error line if you look at the log. (Open up the progress bar and you can see the actual progress of the submit process occurring.

If this is yellow, it's only a warning and can be ignored unless you want to upload the asset to the DLS where it would be flagged as old and rejected. The DLS is no longer accepting assets below 3.5, but that doesn't mean you can't use them yourself. The only time an older asset will be flagged as faulty is when there are more severe errors such a typographic errors in the config.txt file, missing required components, faulty or missing dependencies, textures, meshes, etc.

There's a bit of history here with error checking, which I need to tell you before things get too far. Prior to TRS2006, there was very little if any error-checking in the program that caused crashes due to poor content. It wasn't the asset creator's fault because they more or less followed examples as given to them and created workarounds for the quirky code at the time. Without the error-checking, the user found himself looking at the desktop rather suddenly. With the release of TRS2006 back in 2005, the original format went away and Content Manager Plus appeared. Along with "CMP" came stricter error checking. This wasn't as strict as it is today, but it setup what we're seeing today. With this change, users fainted, had severe bouts of rants and rages, but then settled back down to repair assets and create a lot of content. This error-checking process increased with each subsequent version with TS12 and later versions being the most strict.

With this in mind, the error checking has layers of fault tolerance built into it. Generally an older asset can be imported without issue if it meets specific standards set for the assets at the time. If you were to create a build 2.9 asset, but put in stuff from a build 3.5 asset into the model, then program will balk because those 3.5-things didn't exist back when 2.9 assets were first created. This is the same all the way through the process.

Follow Sailor Dan's advice here. He makes some good points regarding Build 3.7 textures and other things which I didn't hit on.
 
History is also important for individual asset types. ... build 3.7. That is a very useful build number for this particular asset, as it uses a much simpler texture structure with very good bump effects. If you build to this version note carefully how the alpha channel of the normal map is used - a lot of textures got this wrong and showed excessive reflection when viewed against the sun. (a)

You can 'ease' the texture using transparency, assuming the user understands that the texture is designed to be used as an overlay and not as a base texture, but there is nothing that automatically produces a blending. The best solution is to provide several similar textures that can be used to create a more gradual transition: for instance, lush green grass, brownish grass, and ballast with a bit of grass. The effect is achieved by careful selection and application during route building, not by any specific feature you can build into the textures themselves. (b)

(a) Thanks for the information Dan. So you're saying the build isn't just a reference but rather a conditional. I'll change my builds to 3.7. But where are you getting this number from? I get you've been doing this for awhile. I'm curious because then what is build 100240 suppose to be signifying?

(b) I was afraid someone was going to suggest this but that'll have to do. None of the other train games I worked with did blending any better.

One more issue I'd like to ask about and that's the AlphaHint=masked. I used this since it's part of the Quarry example. And I read up on it in the Wiki. In plain English, what's it doing? And thanks again for your time.

Rich
 
Hi Rich,

Your textures look great! You can blend textures into each other by moving your mouse faster over the area you are texturing. You can also rotate textures too by using the square brackets ([,]) keys. This isn't recommended for photo-realistic textures such as highly detailed rock textures, but it works well for grass, gravel, sand, and even your textures I think. (a)

....

Are you receiving an actual error on the build number, or is it a warning? (b)

...

Follow Sailor Dan's advice here. He makes some good points regarding Build 3.7 textures and other things which I didn't hit on. (c)

Hey John,

(a) Thanks for taking a look at the textures. I've been having to tweak them to get them to look right in Trainz and I'm noting because of that rotation [] feature a texture can do multiple roles. I find that cool. I'm trying to remember how I created my ground texture for my last Railwork's route, Fort Smith To Heavener. It's a lovely texture but I have no source for it. I'm sure what I did was thinking that time that at any time I could recreate the texture from the ace or tgpcx (whatever it is in Railworks) back to a useable texture. That was five years ago and I don't remember how to do it.

(b) I'm seeing two warnings in some but most I'm just seeing one warning. One is VE48 and it's telling me I'm using an obsolete build number. The other is VE62 where it's telling me a required container 'texture-variants' is missing.

The textures work except for the thumbnails. The thumbnails are a representative of the actual texture but not the thumbnail I'm referencing which is simply a gray box and the name of the texture on it.

(c) It's what I want to try next and see if I can see any difference in the normal map effect on my ground textures. I can't really see much of the normal map effect in Surveyor so far. For the TGA I used a white masked applied to the texture and saved it without the RLE compression and to the top left (whatever that means). In the normal text reference file I'm using the alphahint=masked reference found in the Quarry example. I don't know what it means.

Thanks again for all your help.

Rich
 
100240 is the build for the application. 3.7 is an asset build number. The application build determines the highest asset build number that can be handled. So build 100240 (TRS2019) can handle assets up to build 4.6. TRS12 can handle assets up to build 3.7. http://online.ts2009.com/mediaWiki/index.php/"trainz-build"_number You can pretty much use the trainz version (TS12, T:ane, TRS2019) instead of the application build number, although sometimes service packs made some small changes to asset features.

You can ignore the warnings. In fact that one about the 'texture-variants' shouldn't even be a warning, as it is an optional feature at build 3.7. It is used when you want the ground texture to display differently according to the time of year.

The thumbnail issue is odd, but not significant. Two things have to be right - the texture.txt file name used for the image tag in the thumbnails container and the image file name used for the Primary tag in the texture.txt file - it seems that you might have one of these wrong. If you have multiple items in the thumbnails container then the thumbnail will be selected on size, matching closest to 240x180 - that's another possible reason for the oddity. Also, that container is one where the rule about always having to go via the texture.txt file is not enforced, although it is good practice.

Your images must be saved without RLE compression (later build numbers relaxed this rule, but there seems little point in using compression). I'm not sure what the white mask is or what saving to the top left means - that sounds like the default alignment for an overlay of some sort. The texture.txt file for the normal map should require only 'Primary=whatever' and 'NormalMapHint=normalmap' tags, so that example might be wrong. A lot of the documented tags for the texture.txt file are now redundant.

Just to be quite clear about normal maps: There are two ways of implying height in an image. One uses an image file that is processed as a bump map - the image itself (usually, brightness) indicates the bump height. This is converted to a normal map. This is considered obsolete. The other is a proper normal map. If you view it (it has the exact file structure of an image file) it will appear as shades of purple, with the shading marking the changes in height. This is a proper 'map', not an image. I assume you are using the second type.
 
100240 is the build for the application. 3.7 is an asset build number. The application build determines the highest asset build number that can be handled. So build 100240 (TRS2019) can handle assets up to build 4.6. TRS12 can handle assets up to build 3.7. http://online.ts2009.com/mediaWiki/index.php/"trainz-build"_number You can pretty much use the trainz version (TS12, T:ane, TRS2019) instead of the application build number, although sometimes service packs made some small changes to asset features. (a)

You can ignore the warnings. In fact that one about the 'texture-variants' shouldn't even be a warning, as it is an optional feature at build 3.7. It is used when you want the ground texture to display differently according to the time of year. (b)

The thumbnail issue is odd, but not significant. Two things have to be right - the texture.txt file name used for the image tag in the thumbnails container and the image file name used for the Primary tag in the texture.txt file - it seems that you might have one of these wrong. (c)

I'm not sure what the white mask is (d)

This is a proper 'map', not an image. I assume you are using the second type. (e)

(a) I tried both 100240 and 4.6 and I got errors. Using 4.6 I was getting an issue where the texture itself would not show in the game though it was listed. It was like pushing the grid around. All I did was change the build number back to 2.9 and then the texture behaved like it should. Beats me but I've up the build number to 3.7 and things are better to where I can see more of the normal map seemingly more pronounced or more like I intended. Nothing in stone this was a one shot thing where it didn't work the first time I tried so I quite using 4.6 and 100240. 3.7 is working good though so I'll stick with that. And even with 3.7 I'm still having that thumbnail issue. I changed the thumbnail to jpg and the thumbnail is still not right. I was wondering if maybe excluding the extension would help matters.

(b) I do need to add seasonal textures. I should probably do that next before I make too many textures. Thanks for reminding me.

(c) Mostly what I'm trying to do is to be able to find my own stuff fast. Having built routes in the past and done so since 2001 I wish the guys who made the games would undertake a better way of selecting assets rather then the long list we end up with.

EDIT: Hold a sec... in just rereading this post in your reply you wrote "....the texture.txt file name used for the image tag in the thumbnails container...". What texture.txt file is there for the thumbnail? I was referencing the thumbnail directly through the config.txt file as "thumbnail.jpg" There's suppose to be a texture text file for the thumbnail too?

(d) We're in the midst of a storm here so I'm having to type fast just in case we lose electricity but the post I read said to add a white mask overlay because Trainz adds a sheen to the ground texture if it's not there? I saw that somewhere but I don't remember where.

(e) I'm using the purplish normal maps. I use a program called Materialize for making maps like this. Something I picked up while learning Blender.

I saw a fellow mention something about a program for making TGA's. I'm using GIMP but not so willingly. Seems a bit overkill if not confusing to learn. For textures I like to use Affinity Photo. Being a fan of Serif I was mostly using their products for a lot of my computer needs. But they all of a sudden dropped their line of products to create the Affinity line. Beats me but it doesn't export to TGA. I get the reason but it still seems weird they don't include TGA export because using Affinity, you can open TGA. ???

Thanks for much of the info btw. This is what I was saying earlier where Wiki's are good for schematic like teaching but you don't get the personable - do this instead of that which often makes the workflow more sensible. Appreciate all the help I'm getting!

Rich
 
Last edited:
Back
Top