I found a nasty bug.

If you remove all binary layout files(*.LAYOUT.BINLAYOUT) and run GUTS. Then, the editor create binary files automatically, but these files lose all new tags (I'm not sure, but it looks like this). This means that you need to open all layouts with tags in GUTS and save it again, the editor will create the correct binary.
Never remove these binary files!

Chthon, can you compare these binary files?

Binary.rar

0 - creation at saving in GUTS
1- automatic creation at the start

OY! So it turns out that the wonderful file specification I found the other day is either wrong or outdated when it comes to .binlayout files. After some fiddling, I've been able to work out a general idea of how the files work.

Rough spec of .binlayout

Spoiler (hover to show)

Code: [Select]

file:
1 magic 0x0b
1 ??? (can't be version, since it changes)
4 ??? (length from start of file to end of last object?)
2:[] objects
46? ???


object:
4 length (inclusive)
1 type (1-byte code for "descriptor")
8 GUID
2:[] (unicode string) name
1:[] properties
4:[] logic
2:[] child objects


property:
2 length (exclusive)
1 type (1-byte code for which property this is)
X data

Unfortunately, it's not a ton of help. The two files you gave me differ in a handful of places that I understand and know aren't important (tiny rounding errors in the 3D orientation of Hidden_Treasure_Standart) plus two places that I don't understand. One of these places is the second byte of the file. This was 0x36 in file 0 and 0x04 in file 1. The file spec says that this byte is the version number. Obviously, it isn't. But I don't have a clue what it really is, or if it matters. The other place is in a section at the end of the file beyond the end of the last object. One value changes from 184 in file 0 to -1 in file 1. This section does not exist in the file spec, and I have no clue what any part of it does.

Since I've got no clue if either of these differences is to blame, the best I can do is propose an experiment:
I've attached files 2, 3, and 4.
file 2: changed just the second byte
file 3: changed just the value near the end
file 4: changed both
Try substituting these for the binary to see which, if any of them, result in a working layout in-game.

(Btw: Does 184 mean anything to you? An ID number for one of your custom tags? A number near but not exceeding the total number of files in your mod?)

Quote from: Chthon on September 07, 2015, 08:44:05 am

(Btw: Does 184 mean anything to you? An ID number for one of your custom tags? A number near but not exceeding the total number of files in your mod?)

Hmm, you know, now I have 32 new tags. As I remember the game has 152 static tags. 152+32=184!

Hypothesis: If file 3 and/or file 4 works, and file 2 does not work, then maybe this value near the end is "how many feature tags must be loaded before this layout can be loaded."
[Edit: You ninja'd me. If that particular tag is number 184, then it might also be the sole item in a list of tags to load first. (Or it could be unrelated. We'll (maybe) know after you try the experiment.)]

The other place is in a section at the end of the file beyond the end of the last object. One value changes from 184 in file 0 to -1 in file 1. This section does not exist in the file spec, and I have no clue what any part of it does.

Yes, I found this place. It's definitely Tag ID.



Well, I have two news - good and bad. 

Bad:
It seems that it is impossible to add IDs for these tags. I tried several variants, none of them works.
My experiments have discovered that ID really depend on the name and assigned in alphabetical order.
All this means - if you add a new tag that violate alphabetical order, you will get a lot of trouble with your old tags.

Good:
It looks like I've found a way to control new tags.
No matter how your tags are called "in reality", it is important how your files are called. Because the alphabetical order applied to this files.
For example:
I have a tag - "EC_DEADS"
[EC_DEADS]
<STRING>NAME:EC_DEADS
[/EC_DEADS]You can name your file completely different, say ID176 or Teg176 or "MyFirstNewTag" - this does not affect on your tag. But for control your tags, you must use a clear and simple name system.
I think you should call your files as follows:
1.dat
2.dat
3.dat
...
999.dat

or

TAG001_MYFIRSTTAG.dat
TAG002_MYFIRSTTAG2.dat
TAG003_MYSECONDTAG48.dat
...
TAG999_INEVERGIVEUPTAG.dat

But I think it would be more convenient to use IDs in the file names. We now know that the game has 152 static tags and all dynamic tags begin at 153. Just use the ID in the name and you will always know your tag ID.
Say:
ID153_EC_DEADS.DAT
ID154_EC_DEAD_P01.DAT
ID155_EC_DEAD_P02.DAT
...
ID184_MY_LAST_TAG.DAT

Spoiler (hover to show)

I believe that in this way you will never break the alphabetical order and your tags will work fine at any stage of development.

I love watching you guys discover stuff.

He-he.  I hate these tags because they are a bunch of problems, and I love them, because it is an incredible feature!