Talk:OBJS

Types

I guess the rule for types is something like this:

ID, ModelName, TextureName, [Clumps, {DrawDistance,...}], Flags

This is the reason for the appearance of the types listed in this article:

Params = 4 (Type 0)
int,  string,     string,       int
ID,   ModelName,  TextureName,  Flags

Params = 6 (Type 1)
int,  string,     string,       int,     float,  int
ID,   ModelName,  TextureName,  Clumps,  DD1,    Flags

Params = 7 (Type 2)
int,  string,     string,       int,     float,  float,  int
ID,   ModelName,  TextureName,  Clumps,  DD1,    DD2,    Flags

Params = 8 (Type 3)
int,  string,     string,       int,     float,  float,  float,  int
ID,   ModelName,  TextureName,  Clumps,  DD1,    DD2,    DD3,    Flags

Params = 5 (Type 4) | SA only - if Clumps not set it will get 1)
int,  string,     string,       float,  int
ID,   ModelName,  TextureName,  DD1,    Flags

Even though it is never used by default there can be up to 8 clumps inside 1 model (in theory even more!)... so there should be also some format like this:

int,  string,     string,       int,     float,  float,  float,  float,  float,  float,  int
ID,   ModelName,  TextureName,  Clumps,  DD1,    DD2,    DD3,    DD4,    DD5,    DD6,    Flags

So I am writing this just to clarify if I am wrong. I don't know how the IPL line parser is implemented but basicly I guess it follows the rule I wrote above. This is why I think those "types" which are descriped in the article at the moment are just making it more difficult to understand. Please correct me if I am wrong - it is also possible, that R* implemented the parser something like that: See parameter count --> get type --> parse. Would not be the first unportable thing they produce... --Aschratt - oO 10:11, 24 September 2010 (UTC)

I got these types just by looking at the IDB but I have little knowledge on how things work in that file. I see stuff like "%d %s %s %d %f %d" and that closely matches to what we currently know about OBJS. There were only 5 of these in SA's OBJS section. All sections in both IDE and IPL files are like this so I assumed that if there are only 5 types of OBJS listed, then it is limited to those 5.--Spaceeinstein 21:12, 24 September 2010 (UTC)

Yes, but perhaps R* simply hardcoded some standard cases:

if (numTokens == 5) /* use constant rule */

What you see in the disassembly is the code generated inside this if clause:

sscanf(str, "%d %s %s %d %f %d", modelIndex, modelName, ...);

Maybe R* wrote the code that way, because it speeds up the parsing performance. But writing this for each case would be impossible (if you remember, that clumpCount is not limited to an constant range) or not fast because of too many checks for each line so I think the else clause looks somhow like this:

else { const char str[255]; /* build up format string dynamicly */ scanf(src, str, /* some kind of mapping */); }

And in that case there is no constant format string inside the disassembly. Anyway I am not sure if I am right! Perhaps we should simply test defining an object with 3 or more clumps. This would represent a case you have not listed. If it works then I am right. If not you are ^^ --Aschratt - oO 09:16, 27 September 2010 (UTC)

Ok, I tested an object using 3 clumps with no crash but using 4 and 5 clumps and the game crashed.--Spaceeinstein 05:10, 28 September 2010 (UTC)

Okay, then I guess you are right. Thank you :) --Aschratt - oO 11:23, 28 September 2010 (UTC)

Format

Which of these do you prefer, or do you want something else? The first one uses existing styles and the second one is based on the styles from the opcodes pages.

objs
# type 1
ID, ModelName, TextureName, MeshCount, DrawDistance, Flags
# type 2
ID, ModelName, TextureName, MeshCount, DrawDistance1, DrawDistance2, Flags
# type 3
ID, ModelName, TextureName, MeshCount, DrawDistance1, DrawDistance2, DrawDistance3, Flags
end

objs
# type 1
[int1], [str1], [str2], [int2], [flt1], [int3]
# type 2
[int1], [str1], [str2], [int2], [flt1], [flt2], [int3]
# type 3
[int1], [str1], [str2], [int2], [flt1], [flt2], [flt3], [int3]
end

--Spaceeinstein (talk) 22:36, 2 August 2015 (UTC)

I'd choose the first one. Makes much more sense to me Seemann (talk) 07:50, 3 August 2015 (UTC)