What is the purpose of <TileDesignPath> tag?

After looking at several of the in-game tiles, I am fairly certain that this has to do with a working path change of some kind. I am led to this conclusion by the fact that this tag serves as a breaking point between the various sections which make up the tile. In most of the tile xml files, this tag sits between the props section and the effect section of the layout, which leads me to believe that there is some need for a working directory change between these two sections of the file. However, this could also simply denote a change to the executable to switch from rendering props to rendering effects, which would also benefit from such a breaking line.

Thanks, kenata .

Why the heck am I getting multiple path changes on some tiles, though? Any ideas? Is it how it supposed to be, or is it my fault for having a tile open in both the forge and .xml editor?

For example, I have 2 versions of golems' scenic view tile sitting in my folder. 1 was what I made in the forge. 2nd is exactly the same, except I  scaled down 1 pillar using notepad++, and I think adjusted the height of the arch a little.

First one got <TileDesignPath InternalName="_path0"/>

Second got

<TileDesignPath InternalName="_path0"/>
<TileDesignPath InternalName="_path1"/>
<TileDesignPath InternalName="_path2"/>

I may be worried about nothing, but I don't want to unintentionally introduce any glitches or performace issues with a new tileset.

Anyway I can see the two files? I would like to see exactly where its placing the changes.

Sure thing,  HERE.

I was under the impression that those tags - somehow - defined what objects would be shown when hovering your mouse deciding where to build an improvement.

I recently went through a test and I am fairly certain the additional paths are not necessary. If I had to fathom a real guess as to what happened, my guess would be that the system performs a simple consistency check in cases where it is unsure whether it should perform a specific function or not. In the case where this check shows that more work is required, you end up with the multiple paths thing. Let me give you a scenario and it will be more clear. You create a tile in the editor and save it. When the tile is saved, you traditionally end up with three things, a tile xml file and two shadow files. Now, you load up your tile xml file in a text editor and you make some minor modifications which may not be possible in the editor. At this point, your shadows are not current, though perhaps this is workable from some aesthetic point of view. So you load the file up in the editor and overwrite your original save to update the shadows. Since you did not actual make a change to the tile in the editor, it runs this simple check on the shadow files to make sure they are ok before performing the intensive task of writing out a new set of shadows. It then loads up both shadow files and does its check. Since the shadows are out of date, the engine writes a new set of shadows and updates the tile xml file resulting in the multiple path tags. I have run several tests along these lines, and have found result to support this hypothesis. The only time I have received multiple path tags was in the case where I did not make a change to the tile and I overwrote the open file. In all other tests, my results were the same, a single path tag in the tile xml.

That makes sense. Thanks for the example, and especially for looking into it!

I think I'll just leave the multiple paths in the tiles .xml files for now then. Or maybe delete all the paths and reopen them in the editor and resave. 

Ok so, here is the crazy part. This is part of a conversation with Cari_Elf.

*laughs* That was much ado about nothing, then.

Good bit of knowledge, still .

LOL, I just checked on this thread doing research for "Curses".  Give the little people paths... hehehe