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: What you see in the disassembly is the code generated inside this if clause:
if (numTokens == 5) /* use constant rule */
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:sscanf(str, "%d %s %s %d %f %d", modelIndex, modelName, ...);
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)else { const char str[255]; /* build up format string dynamicly */ scanf(src, str, /* some kind of mapping */); }
- Yes, but perhaps R* simply hardcoded some standard cases:
- 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)