Temple.dll Object Fields

I've begun building a comprehensive list of object fields based on the temple.dll data structures.

Attached is my first list. The field names are based on a separate table of field names in temple.dll. Sitra already found out that the field names there seem to be outdated and are only correct for the higher field numbers.

Next steps:

• Figure out how proto idx relates to protos.tab column
• Figure out the correct field names
• Finish deciphering the data formats

 

Technical info:

The information about each field is extracted from the table @ 10B3D7D8 (It's a pointer to the table actually).

The field names were extracted from the table @ 102CD840

The type names were extract from the table @ 102CD7F8

Whether a field applies to a certain type was determined by calling the function @ 1009C190 (DoesObjectSupportType) with all fields and types.

 

Another relevant bit: the field types (e.g. 32bit, 64bit, object, list, etc.) are determined in the function

1009B0D0 ; int ObjPropsDefTable_TypesInit(void)

i.e. they're manually hardcoded in the function.

Another remark: Field 4 is different than -1 only for array (idx) fields (types 5,6,7,8,9, 13, 14). And similar to field 0 (proto idx) it's a running index that depends on the object type.

 

Using Agetian's World Builder as reference, as well as some cross references from the DLL, I've managed to sort out fields 1-25 which seems to be the problematic range (where the DLL field names don't match their actual use).

See documentation at the TemplePlus wiki:

https://github.com/CircleOf8/DllDocumentation/wiki/Object-Fields

 

Thanks! That's extremely helpful

 

I haven't explored that, but I'd imagine the code for lighting first checks if the object in question is a static, if it even attempts to cast light from mobs at all. I doubt it's an easy / trivial change, but it sounds doable.

 

Aren't light sources baked into the background JPGs statically?

 

I think he's talking about lighting the characters - that's definitely affected by light sources dynamically. Affecting the JPGs would be harder, but maybe adapting the day/night code could enable that too.

 

Yeah i implemented that day/night stuff back in EvilTemple and it applied to all pixels of the JPG uniformly. The issue with doing dynamic lighting on the backdrop really is that it would not respect the clipping geometry, so the light halo would "go through walls".

Adding lights that only apply to characters is definetly more doable than that.

But btw, there *are* techniques that could apply dynamic lights using the clipping geometry, but I don't know if I have enough 3D expertise for that or if the clipping geometry is even high enough quality for it.

 

Not to mention, KotB has no DAGs since they're user generated maps... but really, let's not get carried away

 

If you want to see how that's done, check out Pillars of Eternity. They basically use the same approach as ToEE in terms of 2D backgrounds, 3D depth art and 3D models. And I think they are applying lighting to the 2D backgrounds using a normal map in addition to the depth art, but we don't have that luxury.

 

While many won't notice that, I can say that the effort is really appreciated from a player's perspective. Walking behind things in the keep and having the clipping fully kick in really helps add to the 3D feel of the map.