Jump to content

[Weidu] How to make COPY_EXISTING (or whatever) copy some large TIS file to the Override folder


Constantine

Recommended Posts

Posted

How to make COPY_EXISTING copy some large TIS file to the Override folder? In other words, I need to extract some TIS from the biff file to the override and rename it according to my new area file name. Why? Because it makes a huge difference then you download 1 MB or 51 MB mod package thanks to the large TIS file that already exists in the game.

I've found some old discussion on the forum about using COPY_LARGE or some similarly useless advice. Now, is there a working solution?

Posted

Sounds like a wiedu bug (odd limit) or feature request (no COPY_EXISTING_LARGE). For the time being you could extract/delete the file with a manual weidu call in some preparation scripts (like those usually used for music conversion).

Posted
Sounds like a wiedu bug (odd limit) or feature request (no COPY_EXISTING_LARGE). For the time being you could extract/delete the file with a manual weidu call in some preparation scripts (like those usually used for music conversion).

I fear this is the only solution so far. Thanks.

 

You could simply write the old tis name in the wed file.

Yes I tried this but the fact is that either biff containing the TIS file should be uncompressed to the cache/data folder (something you cannot rely upon) or TIS itself should be in the override for this solution to work.

Posted
Yes I tried this but the fact is that either biff containing the TIS file should be uncompressed to the cache/data folder (something you cannot rely upon) or TIS itself should be in the override for this solution to work.
Right, the game will crash if the referenced resource (like a .tis or .wav) is in a different compressed biff than the .are/.wed files. However, there should be an undocumented DECOMPRESS_BIFF command to work around this - at least, I don't see it in the WeiDU documentation I have but I could've sworn it was put in several WeiDUs ago (see here).
Posted
Right, the game will crash if the referenced resource (like a .tis or .wav) is in a different compressed biff than the .are/.wed files. However, there should be an undocumented DECOMPRESS_BIFF command to work around this - at least, I don't see it in the WeiDU documentation I have but I could've sworn it was put in several WeiDUs ago (see here).

Well, yes, the DECOMPRESS_BIFF command decompressed the biffc, BUT to do so, I needed to manually copy it to the destination folder, it appears it can't be found automatically. Besides that, the uncompressed bif should be in the cache/data folder, not the data folder, otherwise the game crashes. And the cache as I understand can be flushed at any time.

Posted

DECOMPRESS_BIFF ~cd3/data/area110a.bif~ ~cd3/data/area140a.bif~ <etc>

 

This will backup the listed file(s) and overwrite them with an uncompressed copy. This is enough for me to prevent CBIF-related crashes.

Posted
DECOMPRESS_BIFF ~cd3/data/area110a.bif~ ~cd3/data/area140a.bif~ <etc>
I think that worked for me too. As an action (not a patch) it didn't need a separate COPY. If you don't know which .bif it's in or whether it's compressed, the related commands (FILE_IS_IN_COMPRESSED_BIFF, BIFF_IS_COMPRESSED, SOURCE_BIFF) should resolve that.
Posted
DECOMPRESS_BIFF ~cd3/data/area110a.bif~ ~cd3/data/area140a.bif~ <etc>
I think that worked for me too. As an action (not a patch) it didn't need a separate COPY. If you don't know which .bif it's in or whether it's compressed, the related commands (FILE_IS_IN_COMPRESSED_BIFF, BIFF_IS_COMPRESSED, SOURCE_BIFF) should resolve that.

So you assuming area110a.bif is located in the cd3/data/ folder? Will DECOMPRESS_BIFF search for it in the path specified in the baldur.ini?

It's strange, I am sure I've placed the uncompressed bif to the data folder (not cache/data) and the game still crashed. Thanks anyway. I suppose it doesn't matter now, I've fixed the issue like lynx suggested in the second post.

Posted
So you assuming area110a.bif is located in the cd3/data/ folder? Will DECOMPRESS_BIFF search for it in the path specified in the baldur.ini?

It's strange, I am sure I've placed the uncompressed bif to the data folder (not cache/data) and the game still crashed. Thanks anyway. I suppose it doesn't matter now, I've fixed the issue like lynx suggested in the second post.

WeiDU knows how to look into baldur.ini to find it in another path; however, commands that operate on existing biffs need the full path to the file (as contained in chitin.key).

Posted

This will work. The code is unnecessary long though for a few reasons:

1) SOURCE_BIFF should return the CD# the data/*.bif is in (unless it's in the main data folder).

2) SOURCE_BIFF should be (or have at least) an action usage; it makes little sense as a patch since by principle, WeiDU can't patch humongous files like biffs.

3) There's a lot of ACTION_IF checks and PRINT messages in here that aren't strictly necessary (useful mainly for debugging or information).

ACTION_IF FILE_EXISTS_IN_GAME ~ar1101.tis~ BEGIN
 ACTION_IF NOT FILE_EXISTS ~override/ar1101.tis~ BEGIN
PRINT ~No ar1101.tis in override, checking BIFF compression ...~
OUTER_PATCH null BEGIN
  SOURCE_BIFF sbif ~ar1101.tis~
  TO_LOWER sbif
END
OUTER_TEXT_SPRINT bcd ~~
ACTION_IF NOT FILE_EXISTS ~%sbif%~ BEGIN
  ACTION_IF FILE_EXISTS ~cd2/%sbif%~ BEGIN
	OUTER_TEXT_SPRINT bcd ~cd2/~
  END ELSE BEGIN
	ACTION_IF FILE_EXISTS ~cd3/%sbif%~ BEGIN
	  OUTER_TEXT_SPRINT bcd ~cd3/~
	END ELSE BEGIN
	  ACTION_IF FILE_EXISTS ~cd4/%sbif%~ BEGIN
		OUTER_TEXT_SPRINT bcd ~cd4/~
	  END ELSE BEGIN
		ACTION_IF FILE_EXISTS ~cd5/%sbif%~ BEGIN
		  OUTER_TEXT_SPRINT bcd ~cd5/~
		END
	  END
	END
  END
END
ACTION_IF FILE_IS_IN_COMPRESSED_BIFF ~ar1101.tis~ BEGIN
  PRINT ~Found ar1101.tis in compressed BIFF %bcd%%sbif%; decompressing ...~
  DECOMPRESS_BIFF ~%bcd%%sbif%~
END ELSE BEGIN
  PRINT ~Found ar1101.tis in uncompressed BIFF %bcd%%sbif%; no action.~
END
 END ELSE BEGIN
PRINT ~Found ar1101.tis in override; no action.~
 END
END ELSE BEGIN
 PRINT ~No ar1101.tis in the game; check your filename.~
END

But anyway it beats using external OS-dependent script/batch files etc.

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...