Question on .2da files limitatiions

[peacy66 0]

Hi, i tried to search for an answer to this next question on forums but couldn't find any clue(maybe i search real bad too). I just replayed kotor1 and i added tons of mods (60+) most of it was running well with some exceptions wich is normal because so many mods. Anyway 1 thing that annoyed me greatly is my appearance.2da was somehow mixing those appearance from the last entries in my 2da file(suppose to have xwingpilot but i get a BOSSR appearance) while the heads and all info were supposed to work the info was well entered thus shud have given me the right models. So my conclusion was that there is a limit to the number of entries in 2da files. Then i ask u all proffessional modders: Whats the limits entries per 2da files if u know it. appearance=? heads=? portraits=?  baseitems=?  itemcreate,itemcreatemira=? spells=? upcrystals=? upgrade=? . I hope someone have a clue about this and Ty very much for all the great mods u guys put in here...probly tried em all. yall awesome..

 

[Fair Strides 509]

There's actually no limit on the number of rows.

 

There's various ways that the files interact and share information (if anyone's good with art, do you want to help me make a flow-chart? ), but long-story short is that the NPC and creature file (.utc files) reference a row in the appearance.2da file for their appearances in-game. It's the same with the scenery objects and containers, but with placeables.2da. Ditto for doors, but it's genericdoors.2da.

 

The heads are linked to the appearance.2da with the normalhead and backuphead columns in appearance.2da, and that's it.

 

The portraits are linked to the appearnce.2da with the three appearance columns in portraits.2da telling the game which appearance.2da rows use that portrait set.

[Antonia 5]

In all fairness, there probably *is* an upper limit on just how much data/how many entries can be read in from a given 2da file, but to figure out exactly what that limit is, we'd need to decompile the exe and see what it's doing.

 

That said, there is *no* way you've found that limit. My own appearance.2da file for example is currently only up to 514 rows, but I've used one before with over 1200 rows and it caused no issues whatsoever.

 

As I said, I'm not exactly certain exactly how they've set up the data where the engine reads these things, but they definitely gave it more than enough room, so that's not your issue.

 

-Kitt

[Kexikus 994]

The reason for those wrong heads is that different mods added/edited the same line and thus one was overwritten. And when items/appearances from both mods reference that line, one of them won't do what it's supposed to do.

 

This can be avoided with TSLPatcher but some older mods might not do this.

[Malkior 476]

While we're on the topic, why then would a mod conflict cause a character to be missing their heads or for the body to be the default (mannequin) appearance? I had always assumed that was due to the 2da reaching its row limit.

 

However, if this is actually a mod writing on the same row as another, how come it becomes invisible rather than flat-out replacing it? (For example, the Handmaiden sister model fix caused this issue when I used it on my older installation)

[Fair Strides 509]

While we're on the topic, why then would a mod conflict cause a character to be missing their heads or for the body to be the default (mannequin) appearance? I had always assumed that was due to the 2da reaching its row limit.

 

However, if this is actually a mod writing on the same row as another, how come it becomes invisible rather than flat-out replacing it? (For example, the Handmaiden sister model fix caused this issue when I used it on my older installation)

As to the first paragraph, Malkior, this can happen if the mod tells TSLPatcher to replace the appearance.2da file in the user's override folder with the one from the tslpatchdata folder before making changes to the file...

[Malkior 476]

As to the first paragraph, Malkior, this can happen if the mod tells TSLPatcher to replace the appearance.2da file in the user's override folder with the one from the tslpatchdata folder before making changes to the file...

Okay, then it's basically due to a poorly set up installation by the mod author? So, if I were to encounter this kind of conflict, would it be easy to fix?

(I ask because a few mods were making me avoid them due to their conflicting with my installation, and let's face it, compatibility between appearance mods across the board would be a wonderful thing. )

[Antonia 5]

It's not *hard* really.. You can usually make any number of appearance-based mods compatible with some fairly simple 2da edits. Knowing exactly what you'd need to do though depends a lot on exactly what your'e trying to merge, and which one(s) aren't doing what they're supposed to already.

 

-Kitt

[peacy66 0]

Ok, good to know theres no limit, i was sure i double checked those appearance to fit their heads but i guess with too many entries i got lost somewhere.....TY for answering now i'll just make the same with tsl, but ill try to be more cautious, i guess i made a dumb mistake on kotor appearance 2da, i had over 700 entries so easy to have a mistake somewhere. Once again ty all modders for ur mods.

[DarthParametric 3,777]

Okay, then it's basically due to a poorly set up installation by the mod author?

Not necessarily. Some mods still in circulation pre-date the existence of TSLPatcher.

[Malkior 476]

Not necessarily. Some mods still in circulation pre-date the existence of TSLPatcher.

Fair point.

 

I guess it may be prudent to get a hold of mod authors and see if we can make more classic mods compatible.. :/

[DrMcCoy 40]

In all fairness, there probably *is* an upper limit on just how much data/how many entries can be read in from a given 2da file

 

Well, for binary 2DA, the ones KotOR use, the number of colums has a hard limit of 2^32, because the count value is given as an uint32_t. For symmetry's sake, I bet the row counter also uses a 32-bit integer in the binary. I'm too lazy to check though. If they're sloppy with their arithmetics, you might want to limit yourself to 2^31, though.

 

That said, there's a more important limit: the offset to the cell data is given by an uint16_t. So your 2DA file will get issues when it reaches 65535 of raw cell data. This is not necessarily the file size, because that is excluding the row counters and column headers, and the cell data offset table. Also, the same data in multiple cells is only saved once.

 

64kb of unique cell data is difficult to reach, though. My original, unmodded appearance.2da for KotOR2, which is 148884 bytes big (i.e. ~ 146kb), only reaches a max offset value of 19222 (~ 18kb). Yes, 129662 bytes, 87% of the file, is taken up by the row counter, colum headers and the cell data offset table.

 

That said, if the file is actually exceedingly large, and has a lot of unique cell values, you certainly can reach that, if you tried. If the program you use to write the 2DA files doesn't check for that, it can theoretically overflow these offset. But: these broken offsets will most probably not point to the beginning of a valid cell, but in the middle of one. So you won't get duplicated values, but bogus ones. (It is probably possible to intentional rig up a file to do surprising things, though.)

 

EDIT: Oh, but if you're using ASCII 2DA files (does KotOR still read those?), this all is of course not applicable. Unless the first converts them into binary ones in memory. Which is possible, but I don't think it's likely.

[Hassat Hunter 571]

Actually, there is a limit:

http://deadlystream.com/forum/topic/2068-more-than-1000-globalnumbers/?hl=globalcat.2da

[DrMcCoy 40]

Actually, there is a limit:

http://deadlystream.com/forum/topic/2068-more-than-1000-globalnumbers/?hl=globalcat.2da

...But that's about a completely different issue?