[ARE V1.0] Doors

[Ascension64]

Current IESDP ARE V1.0 Doors description contains:

0x0048 4 (dword) Index of first "vertex" in the impeded cell block (when closed). These are not actually vertices, they are instead cell coordinates (each cell corresponding to one tile in the WED file's tilemap structures. When the door is closed, these cells cannot be entered by any object.

0x004c 2 (word) Count of "vertices" in impeded cell block (when closed)

0x004e 2 (word) Count of "vertices" in impeded cell block (when open)

0x0050 4 (dword) Index of first "vertex" in the impeded cell block (when open). These are not actually vertices, they are instead cell coordinates (each cell corresponding to one tile in the WED file's tilemap structures. When the door is closed, these cells cannot be entered by any object.

 

There are a few errors in this:

1. the "when closed" and "when open" labels are the wrong way around, i.e. 0x48 and 0x4c contain the impeded points when the door is open, and 0x4e and 0x50 contain the impeded points when the door is closed

2. the coordinates do not correspond to tiles in the WED file, but do correspond to [x.y] coordinates in the search bitmap (<area>SR.bmp)

2. it is worth not using the word "vertex/vertices" at all and refer to them as "search map coordinates"

 

Proof by reversing assembly code (look at memory offsets 0x4EAB04 when door open and 0x4EAD05 when door closed).

[lynx]

You bothered with reversing it? Doors already work in gemrb, so you could've saved plenty of time by checking our ARE importer/plugin.

 

		str->ReadDword( &OpenFirstImpeded );
	str->ReadWord( &OpenImpededCount );
	str->ReadWord( &ClosedImpededCount );
	str->ReadDword( &ClosedFirstImpeded );

 

Btw, the next dword is uknown, so if you find out anything useful about it, do tell.

[Ascension64]

Heh, it's not easy to marry GemRB offsets (lots of adding up) with reading straight from IESDP.

The reversing was unintentional and came out of my research into why Beregost was crashing.

 

If I find anything about the next dw, will let you know.

 

Update

The dword is entirely unused.

 

AreaDoor.dw54 is constructed as 2 words (w54, w56). Apart from marshal and unmarshal from the AreaDoor struct, it does nothing in-game.

 

Pseudocode in CDoorObject::Unmarshal() {

pAreaDoor->w54 ? pDoorObject->w490 = pAreaDoor->w54 : pDoorObject->w490 = 20;

pDoorObject->w492 = pAreaDoor->w56;

}

 

Pseudocode in CDoorObject::Marshal() {

pAreaDoor->w54 = pDoorObject->w490;

pAreaDoor->w56 = pDoorObject->w492;

}

[lynx]

gemrb usually uses variable names like in the iesdp, unless they are wrong. So it is easy to search for them, since the engine is pretty complete and all known stuff has to be loaded/saved to prevent corruption.

 

Thanks.

[Avenger]

Well even dltcep has it in the open, open, closed, closed order. Most likely NI is correct too.

 

Actually, NI has it like IESDP

[Ascension64]

There are a few versions of NI floating around... the one I am using is incorrect. I think it is the 10/02/08 revision.

[devSin]

If you truly have the latest version, it should be correct (they were reversed for years and years; I finally flipped them around). I think the one up on git has the change.

	list.add(new DecNumber(buffer, offset + 72, 4, "First vertex index (impeded, open)"));
list.add(
		new SectionCount(buffer, offset + 76, 2, "# vertices (impeded, open)",
						 OpenVertexImpeded.class));
list.add(new SectionCount(buffer, offset + 78, 2, "# vertices (impeded, closed)", ClosedVertexImpeded.class));
list.add(new DecNumber(buffer, offset + 80, 4, "First vertex index (impeded, closed)"));

[Miloch]

The latest compiled version of NI still has it wrong. Maybe it's time for someone to compile and upload an update...