-
Bravo! Bravo!
-
-
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 -
-
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
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?) -
-
(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!
And my tag "Hidden Treasure" is now last in alphabetical order.
-
-
(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.)] -
-
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."
I have another hypothesis:
When you start the editor all dynamic tags get "extension static" ID in alphabetical order.
(I had a suspicion that something was wrong when I added more new tags - the previous broken. Now I understand that the problem can be in this.)
As we know, all static tags have IDCode: [Select][EC_DEADS]
<INTEGER>ID:155
<STRING>NAME:EC_DEADS
[/EC_DEADS]
[EC_DEAD_P01]
<INTEGER>ID:153
<STRING>NAME:EC_DEAD_P01
[/EC_DEAD_P01]
[EC_DEAD_P02]
<INTEGER>ID:156
<STRING>NAME:EC_DEAD_P02
[/EC_DEAD_P02]
[EC_DEAD_P03]
<INTEGER>ID:157
<STRING>NAME:EC_DEAD_P03
[/EC_DEAD_P03]
I suppose I should add ID manually into all of my new tags, otherwise I will have big problems in the future when I add new tags.
But while I'm not sure that this will help. I'll try it tomorrow.
-
-
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"Code: [Select][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.
<STRING>NAME:EC_DEADS
[/EC_DEADS]
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
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.
-
-
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!
-