Need help with a graphic glitch

[plainab]

In Tutu and Easy Tutu the bridge area known as FW0900.are (AR0900.are in a BG1 install) has a gap in the drawbridge once it has been lowered. I have been able to compare the original BG1 files to the E22 files and have noticed that the drawbridge door has an alternate tileset. The entries between both versions are different. I am able to adjust the entries via DLTCP and get the E22 area correct. But I'm looking for a WeiDu patch to get the job done. I've been able to locate the first tileset entries, but the alternate set is supposed to be somewhere within the TIS file according to the IESDP. However, there is no listed offset to take me to the doors portion within the TIS file. Does anybody out there know how I can get to those values so that I can correct them?

 

Thank you.

[Miloch]

Anyone able to help with this? Seems to me Yovaneth did something similar.

 

Edit: That post is here.

[Nythrun]

Check the .wed for indicies to the .tis to patch the .are...

[plainab]

Check the .wed for indicies to the .tis to patch the .are...

I've done that. I've looked everywhere I can.

I probably don't know how to read the IESDP properly.

 

The .are file doesn't actually get patched. The .wed file is where all the door information is at. DLTCEP shows both sets of indicies in the wed file, but IESDP only gives me information to get to the main set. IESDP tells me that there should be two sets (one for open and one for closed) but doesn't say how to get to the second. I've tried everything I could think of, but to no avail. I'm not the programming trained person that the IESDP assumes is reading it, so I'm probably missing something.

 

If someone could explain the IESDP, and get me where I need to be going with that.

OR

Take a look at the specific situation and post some code to fix it.

 

I would be one happy camper.....

[Nythrun]

Sorry, I guess that wasn't very funny.

 

You're looking for the door closed state, correct?

[Nythrun]

Chances are you'll want something like this, though I'd have to look at the file to be sure.

ACTION_IF (FILE_EXISTS_IN_GAME ~fw0900.wed~) THEN BEGIN
 COPY_EXISTING ~fw0900.wed~ ~override~
PATCH_IF (SOURCE_SIZE > 0x34) THEN BEGIN
  READ_LONG 0x0c		  "dc"			  // doors count
  READ_LONG 0x14		  "h2"			  // offset to secondary header
  READ_LONG 0x18		  "do"			  // offset to doors
  READ_LONG ("h2" + 0x04) "po"			  // offset to polygons
  READ_LONG ("h2" + 0x08) "vo"			  // offset to vertices
  FOR ("i1" = 0x0; "i1" < ("dc" * 0x1a); "i1" += 0x1a) BEGIN // loop through doors
	READ_ASCII ("do" + "i1" + 0x00) ~dn~	// doorname
	PATCH_IF (~%dn%~ STRING_EQUAL_CASE ~DOORDRAW~) THEN BEGIN
	  READ_SHORT ("do" + "i1" + 0x0a) "ti"  // door tile index
	  READ_SHORT ("do" + "i1" + 0x0c) "tc"  // door tile count
	  READ_SHORT ("do" + "i1" + 0x0e) "oc"  // polycount for open state
	  READ_SHORT ("do" + "i1" + 0x10) "cc"  // polycount for closed state
	  READ_LONG  ("do" + "i1" + 0x12) "oo"  // offset to polygons for open state
	  READ_LONG  ("do" + "i1" + 0x16) "co"  // offset to polygons for closed state
	  SET "i1" = ("dc" * 0x1a)			  // halt loop
	END									 // PATCH_IF correct door found
  END									   // loop through doors
  FOR ("i1" = 0x0; "i1" < ("cc" * 0x12); "i1" += 0x12) BEGIN
	READ_LONG  ("co" + "i1" + 0x00) "vi"	// index to vertices for this polygon
	READ_LONG  ("co" + "i1" + 0x04) "vc"	// count of vertices for this polygon
	FOR ("i2" = ("vi" * 0x2); "i2" < (("vi" + "vc") * 0x2); "i2" += 0x2) BEGIN
	  READ_SHORT ("vo" + "i2" + 0x00) "vx"  // finally, a vertex
	  PATCH_IF ("vx" = ??) THEN BEGIN	   // patch if it's a vertex you want to move
		WRITE_SHORT ("vo" + "i2" + 0x00) ?? // move it
	  END
	END
  END
END
 BUT_ONLY
END

[pro5]

If you just want to fix this specific Tutu door, following should be enough:

 

COPY_EXISTING ~FW0900.WED~ ~OVERRIDE~
 READ_LONG 0x10 overlay_off
 READ_LONG overlay_off+0x10 tilemap_off
 WRITE_SHORT tilemap_off+2762*0xa+4 4840
 WRITE_BYTE  tilemap_off+2762*0xa+6 0
 WRITE_SHORT tilemap_off+2763*0xa+4 4841
 WRITE_BYTE tilemap_off+2763*0xa+6 0
 WRITE_SHORT tilemap_off+2764*0xa+4 4842
 WRITE_BYTE tilemap_off+2764*0xa+6 0
 WRITE_SHORT tilemap_off+2841*0xa+4 4847
 WRITE_BYTE tilemap_off+2841*0xa+6 0
 WRITE_SHORT tilemap_off+2842*0xa+4 4848
 WRITE_BYTE tilemap_off+2842*0xa+6 0
 WRITE_SHORT tilemap_off+2843*0xa+4 4849
 WRITE_BYTE tilemap_off+2843*0xa+6 0
 WRITE_SHORT tilemap_off+2920*0xa+4 4853
 WRITE_BYTE tilemap_off+2920*0xa+6 0
 WRITE_SHORT tilemap_off+2921*0xa+4 4854
 WRITE_BYTE tilemap_off+2921*0xa+6 0
BUT_ONLY

[plainab]

I will look into these....

If one of them works, I'll probably use it.

 

But for my own personal education:

pro5 explain me something.

WRITE_SHORT tilemap_off+2762*0xa+4 4840
 WRITE_BYTE  tilemap_off+2762*0xa+6 0

Where did you pull the 0xa+4 & 0xa+6 from?

I understand the math that is done, but I don't understand where those values are coming from. At least not right now while I'm asking you.....

[Nythrun]

One of them is trying to move a door, the other is moving an overlay, so they're not much alike

 

That's parsed as WRITE_SHORT (tilemap_off + (2762*0xa) + 4) 4840; each entry in the Tilemap structures section is ten bytes long (hence the * 0xa) and + 4 is the index into the .tis for the alternate setting for doors, + 6 is "draw base layer only" as mentioned in tile map structures.

[plainab]

One of them is trying to move a door, the other is moving an overlay, so they're not much alike

Well, I certainly don't want to move the door. I only need to adjust overlay values for the doors alternate state. So I should be looking more into pro5's code then, correct?

 

That's parsed as WRITE_SHORT (tilemap_off + (2762*0xa) + 4) 4840; each entry in the Tilemap structures section is ten bytes long (hence the * 0xa) and + 4 is the index into the .tis for the alternate setting for doors, + 6 is "draw base layer only" as mentioned in tile map structures.

I saw that in the IESDP but didn't quite understand how to get at it. The way I understood it, that entry pointed to something in the.tis file and so I thought I needed to load up the .tis file and find it there, not realizing that the info I wanted was in that spot. Oh, well. It's still clear as mud, but if pro5's code works I should be able to adapt it to my purposes....