KOTOR1 Placeable Limit

[ndix UR 218]

While trying to install a mod that added entries to placeables.2da, I came across a relatively severe limitation in KotOR that I feel should probably be known to anyone attempting to make or use large-scale or placeable mods. Maybe this is known or was documented on lucasforums, but I didn't find it anywhere.

 

Unique placeables defined in placeables.2da are limited to 256 (0-255). If you use a value higher than 255 for 'Appearance' in a UTP file, it rolls over. So 256 = 0, 257 = 1, etc.

 

That might not sound like a big deal, but the vanilla game already has 232 placeables, which means that there are only 24 placeable slots available for use by modders. K1R adds 8 placeables, so if you're using that, you have 16 slots available. BOS:SR 1.5 adds 21 placeables, so if you're using that, you have 3 slots available. And if you're using both of those mods you're already over by 5. So people using K1R and BOS:SR can't use any additional placeable mods (and should experience some visual errors in-game from getting the wrong placeables).

 

This seems like key info for users to be able to evaluate what mods they want to try and use based on how many placeable slots they use. It is also among the first things to check if you have any problems with placeables not showing up or showing up as the wrong thing.

 

I am wondering if any experienced modders know or will be able to think of viable workarounds for this? I've tried putting placeables.2da into module files (and removing it from Override/), but that doesn't seem to work. My only other thoughts have been:

• Making certain placeables characters instead of placeables? You lose any walkmesh related functionality like blocking line of sight...
• Combining certain placeable models and using animation states to swap out the mesh that is showing. For example, BOS:SR includes 6 rock placeables, could it be 3 if one rock was the 'on' state and another was the 'off' state?
• Baking placeables into area geometry? This is more work, harder to make fine adjustments, and you can't interact with the objects at all. It would have the advantage that you could 'easily' lightmap 'each instance' of the placeable though. Now that we have advanced model compilers this is at least a more viable option than in the past...

I can say that this definitely applies to the GOG and Mac Aspyr versions of K1, I don't know about others.

 

FWIW, this limitation doesn't seem to be present in TSL as its vanilla placeables.2da file has more than 300 rows (thanks DarthParametric for checking that).

[DarthParametric 3,782]

One of the things I find curious is that KOTOR uses placesables for everything. In Dragon Age Origins they split out static objects into their own category, "props". Those would get placed into the level during the assembly in the level editor and receive baked lighting. They would be exported as part of the level geometry chunks. Placeables were strictly interactive objects, mostly ones with animations, like chests, etc., and those would get placed in the area editor along with creatures, triggers, etc. I can't remember how Neverwinter Nights handled it, but based on the fact that the KOTOR levels seem to have been directly assembled in 3DS Max, I am guessing they didn't directly use the Aurora Toolset or some KOTOR/Odyssey-specific derivative thereof.

 

In terms of optimum scenarios, I would think removing all static placeables and baking them into the levels would be the best idea. But in terms of practicality that seems like its never going to happen. You'd need to rebuild half the game. Perhaps the process could be streamlined if someone could extract the placeable position data from the GIT in a manner similar to a LYT file that would allow KOTORMax to batch import them. But even then that's the simplest bit. You'd need to create all new lightmap UVs for every static placeable, and bake all the lighting for those new props in every affected level. I just can't see that being a realistic proposition.

 

The other problem is that I believe placeables receive tinting via the GIT. Certainly in TSL at least. If you were to make them static, you'd also then need to retexture them.

 

I think the idea of cleaning out null or unused entries and assigning those rows to major mods like K1R is a good, practical starting point. Beyond that it would be the end-user's responsibility to manage what mods they install that use placeables. Although obviously all mods from now on should carry a warning about it to inform end-users.

 

Fair Strides is rebuilding TSLPatcher, perhaps some sort of row ID check could be implemented into that? It could pop up a warning during installation if the max row ID is exceeded.

[Salk 374]

Very interesting find.

 

I wonder if this kind of limitation may apply to other .2da files as well. In my own KotOR game, I do have 251 slots used. Not much space for anything else there, it seems...

 

DarthParametric, in light of this report from ndix UR I suppose you'll have to pull compatibility between "Diversified Jedi Captives on the Star Forge 1.0" and a bunch of other mods appending to placeables.2da, including K1R?

[JCarter426 1,214]

Wow, I never realized that. My placeable entries for K2 number in the 400s, mostly from testing things, so I never even thought it would be a problem. For K1 it's dangerously closed to the limit at 248. Not that there was much room left in the first place. With this game, I shouldn't be surprised.

 

 

The other problem is that I believe placeables receive tinting via the GIT. Certainly in TSL at least. If you were to make them static, you'd also then need to retexture them.

 

I don't believe they do in K1, but even if they do, the dynamic lighting value in the GIT file could be copied to the model's ambient lighting. They're both standard RGB values (although the way GIT stores those values is... terrible).

 

Of course, the dynamic lighting is only there to help the placeable blend into the area lightmap better. So the point would be moot if you redid the area lightmap entirely with all the new objects. Or throw away the terrible concept of lightmaps completely. The engine should be able to handle dynamic light objects for everything. In the past there has always been a "three at a time" limit, but the game areas have hundreds of them and I think we'd notice if they were blinking out to only show three at a time all the time. I'm also certain I've had more than three at a time via other models with Aurora lights in them (placeables, visual effects, etc). I suspect the limitation was a legacy of the NWN tools and may not be relevant anymore. But redoing the lighting for every area seems as unrealistic a proposition as replacing every placeable in the game.

 

But getting back to the main point, another option would be to convert some placeables to visual effects. Those number in the thousands, so they must use larger data type, meaning more room for us. This could be executed by changing the placeable's appearance to invisible and having a script to apply the visual effect on it on spawn, assuming there's no chance of the effect being cleared by the game. I don't know of anything that would, but I'm not certain.

 

Visual effect replacements could still be animated, provided they utilize a single looping animation, but they couldn't change animations and therefore you couldn't interact with them. And lightmapping would probably be out of the question.

 

 

Very interesting find.
 
I wonder if this kind of limitation may apply to other .2da files as well.

 

The other 2DA files likely do have a limitation, but it's at least a 16-bit integer for some of them, meaning over 65,000 possible lines.

[DarthParametric 3,782]

DarthParametric, in light of this report from ndix UR I suppose you'll have to pull compatibility between "Diversified Jedi Captives on the Star Forge 1.0" and a bunch of other mods appending to placeables.2da, including K1R?

It's still compatible with K1R, as long as you don't install a bunch of other mods with placeables. A mod author can't account for every possible combination. As I said above, we'll just have to provide warnings about the issue. Ultimately managing the problem comes down to the end-user.

[ndix UR 218]

Yeah, it seems to me like only mods that add more than 16 placeables would be incompatible with K1R, if we are thinking of that as part of compatibility. Otherwise, my personal plan would be just to add verbiage like 'This mod uses 4/24 available placeable slots.' to my readme.

 

When you get into the technical weeds of the issue, it relates to the client/server architecture from NWN, and the fact that walkmeshes were a server-side phenomenon designed to prevent clients from cheating. It is in the message from 'server' to 'client' where the 'low byte' cast from full int happens. Because of that, the only place I'd expect to see something similar (for a similar reason) might be in area models or doors, but thankfully neither of those are governed by 2DA lists in the same way. Actually doors sort of are, from genericdoors.2da, but I just checked and they seem to use a proper int and not a byte. So feel free to add many hundreds of door types (vanilla only has 65).

 

I always assumed the 3 light issue was for shadow-casting dynamic lights only. Actually, I've always wondered what limits you could go to by adjusting videoquality.2da ... or whether those values are even really used? It has separate rows for dynamic and shadow-casting, now that I check. I did some testing in NWN not too long ago and it seemed like it could handle more than 3 concurrent shadow-casters.

 

The idea of using visual effects on an invisible placeable is an interesting one.

[DarthParametric 3,782]

The three lights per mesh issue persisted into Eclipse. It was always something DAO modders had to watch out for. It caused merry hell trying to carve up a level into sub-meshes in such a way that you wouldn't get super-noticeable seams.

[djh269 264]

So this why I had issue with a newly added computer panel in BOS when I played it alongside K1R, thanks for clearing this up!

 

I've used placeables.2da in some of my own mods, puts me off using it now for K1 haha. 

 

But like the upgrade.2da can't you get around this by placing dummy lines within the .2da file to be able to add more of your own lines in the .2da file? Please see the below as an example for the upgrade.2da file that corpsecotillion typed out here:

 

"In a thread from a couple years ago (http://deadlystream....ghtsaber +addon), Rece discovered that the upgrade.2da file does this weird thing where after row 31 it wraps back around to row 1, so any crystal you put in row 32 onward will change to a different crystal when you hit the assemble button. The good news is that there is a workaround, but it requires using filler rows. After some serious experimentation I was able to get 14 custom upgrade crystals to work in my game, but any more than that and you'll end up with the crystal changing phenomenon again. Without changing any vanilla upgrade rows, you can only add 7 of your custom crystals to rows 25-31, and then additionally you can add 7 more to rows 27-53. That means rows 32-46 are filler. Type whatever you want into first two columns. It really doesn't matter what you put; the rows simply need to exist as placeholders. Set the upgradetype column to anything EXCEPT 0 so it doesn't interfere with the other upgrade crystals."

[JCarter426 1,214]

Without testing that I can't be sure, but it sounds like that only worked because not all the lines in upgrade.2da are used for lightsaber crystals, making it possible to hack the upgrade system. But all the lines in placeables.2da are for placeables.

 

To clarify, the limitation is due to the way a computer stores information. In the UTP file, the placeable's appearance is stored as an 8-bit integer. Basically, the computer can only count to 256. It knows there are 256 placeables and then it can say this is the 0th placeable, this is the 1st placeable, all the way up to the 255th placeable. It doesn't know how to count beyond that, so it thinks the number 256 is the same as the number 0. So if you input 256, it will read it as 0, and then it will look at line 0 in placeables.2da and it doesn't matter what line 256 was. As far as the game is concerned, it doesn't exist.

 

Other variables in the game use larger data types, like for appearance.2da, and apparently upgrade.2da uses an even smaller one. My guess is at some point in production they counted up how many things there were so they could use the smallest type necessary. It's good for efficiency but it's bad for modding.

[djh269 264]

It is pretty awkward for modding haha. It's annoying not being able to have BOS / K1R together as it's definitely the placeables.2da file causing the problem. 

[Salk 374]

It's still compatible with K1R, as long as you don't install a bunch of other mods with placeables. A mod author can't account for every possible combination. As I said above, we'll just have to provide warnings about the issue. Ultimately managing the problem comes down to the end-user.

Maybe I misunderstood but doesn't "Diversified Jedi Captives on the Star Forge 1.0" add 20 more entries to placeables.2da? If we sum that with the original file's 231 entries we hit 251. K1R adds 8, according to the OP, bringing the total number to 259, meaning 4 too many. Am I wrong?

[DarthParametric 3,782]

The base install adds eight entries, the optional content an additional one. I can mitigate the optional one (sparring circle) with a level model replacement, although that merely makes for a different type of potential incompatibility.

 

Diversified Wounded Republic Soldiers On Taris currently adds twelve of its own, but a number of those are "spares" that I was toying with swapping around with scripting before this issue cropped up. I'll have to revise that and remove the unnecessary ones. In fact I was already replacing the room model in that instance anyway, so maybe I could just dispense with placeables for this one altogether and make them part of the room model. That will probably mess up my staggered animations though.

 

It looks like vanilla entries 8, 9, 47, 62, 78, 90, 94, 97, 115 could all be repurposed by K1R or some other major mod. I dare say there are a few more that are populated but unused in the game.

[Salk 374]

Diversified Wounded Republic Soldiers On Taris currently adds twelve of its own, but a number of those are "spares" that I was toying with swapping around with scripting before this issue cropped up. I'll have to revise that and remove the unnecessary ones.

Oh right, of course!

 

I was confused by having both "Diversified Wounded Republic Soldiers On Taris" and "Diversified Jedi Captives on Star Forge" installed. It's them together taking 20 slots. Sorry.

[Durendal 5]

This explains why my game started getting goofy looking after installing so many mods. Interesting find! Without some sort of outside .dll or modification, I'm not sure how this could be circumvented.

This is very troubling though, since it means that Sleheyron(sp?) has very little room to work with and could be incompatible with a lot of things right out of the gate.

[DarthParametric 3,782]

Any large mod going forward will need to incorporate custom placeables into room models where possible to bypass the issue. If they rely on scripted interactions that can't be done any other way then they'll need to make that clear so end-users are aware and can plan accordingly.

[Guest Qui-Gon Glenn]

This explains why my game started getting goofy looking after installing so many mods. Interesting find! Without some sort of outside .dll or modification, I'm not sure how this could be circumvented.

 

This is very troubling though, since it means that Sleheyron(sp?) has very little room to work with and could be incompatible with a lot of things right out of the gate.

Don't be too troubled...

 

I am sure you have played through the vanilla game and with favorite mods installed.

 

Sometimes you just have to choose. Not optimal, but KotOR Mod Manager never worked that well and got dropped in favor of the TSL Patcher. If development continued, KMM was on a better path for being able to solve this issue, much like ME3CMM does - flawlessly switching mods with a couple clicks.

 

Sigh, old game is old. But we love it, so choose wisely and enjoy!

[CosmicSage 1]

Just finished messing with the placeables.2da, after Parametric's direction that it was affecting visual models appearing. I had a thought, would it be possible to create to placeable.2das, effectively splitting up the game into two halves, and allowing mod commands to effectively pursue either without interruption of  kotor1's file sequence?

[Kexikus 995]

I highly doubt that as it's probably hardcoded for the game to use placeables.2da when looking for the apperance specified in an .utp file.