20 replies to this topic

[Sam.]

So, I'm changing the game version displayed on the options screen to the version of Classic Adventures by patching a couple of things in the BGMain.exe. I figured out how to do it with a hex editor, but now I need the WeiDU code that does the same thing.... I?m afraid I haven?t been able to properly grasp even the simplest WeiDU coding so far, so if anyone can take a couple of minutes to show me the EXACT code needed, I'll be eternally grateful! I don't like asking anyone to "Do if for me!", but for the time being I simply don't have the knowhow to even begin to know how to do it myself.

Note that these are unichar. I?m not sure how WeiDU treats hexadecimals so you might have to remove the ?00?s between the characters (but not this one).

This is for version 0.50

Starting at hex offset ?7759CC?, <32 00 36 00 34 00 39 00 38 00> should be <30 00 2E 00 35 00 30 00 00 00>.

Starting at hex offset ?775844?, <32 00 2c 00 20 00 35 00 2c 00 20 00 30 00 2c 00 20 00 32 00> should be <30 00 2c 00 20 00 30 00 2c 00 20 00 30 00 2c 00 20 00 30 00>.

Starting at hex offset ?775A84?, <32 00 2c 00 20 00 35 00 2c 00 20 00 30 00 2c 00 20 00 32 00> should be <30 00 2c 00 20 00 30 00 2c 00 20 00 30 00 2c 00 20 00 30 00>.

Thanks in advance!

This is an example of what it will look like:

Edited by Sam., 02 June 2009 - 09:39 PM.

[Miloch]

So, I'm changing the game version displayed on the options screen to the version of Classic Adventures by patching a couple of things in the BGMain.exe. I figured out how to do it with a hex editor, but now I need the WeiDU code that does the same thing...

If you've got more than a byte or two to patch, Taimon's method is probably the most efficient:

// part1
OUTER_SET off_part1 = 0x7759cc
OUTER_SET len_part1 = 0xa
OUTER_PATCH_SAVE orig_part1 "" BEGIN
	INSERT_BYTES 0x00 len_part1
	WRITE_LONG   0x00 0x00360032
	WRITE_LONG   0x04 0x00390034
	WRITE_SHORT  0x08 0x0038
END

OUTER_PATCH_SAVE patch_part1 "" BEGIN
	INSERT_BYTES 0x00 len_part1
	WRITE_LONG   0x00 0x002e0030
	WRITE_LONG   0x04 0x00300035
	WRITE_LONG   0x08 0x0000
END

// part2
OUTER_SET off_part2 = 0x775844
OUTER_SET len_part2 = 0x14
OUTER_PATCH_SAVE orig_part2 "" BEGIN
	INSERT_BYTES 0x00 len_part2
	WRITE_LONG   0x00 0x002c0032
	WRITE_LONG   0x04 0x00350020
	WRITE_LONG   0x08 0x0020002c
	WRITE_LONG   0x0c 0x002c0030
	WRITE_LONG   0x10 0x00320020
END

OUTER_PATCH_SAVE patch_part2 "" BEGIN
	INSERT_BYTES 0x00 len_part2
	WRITE_LONG   0x00 0x002c0030
	WRITE_LONG   0x04 0x00300020
	WRITE_LONG   0x08 0x0020002c
	WRITE_LONG   0x0c 0x002c0030
	WRITE_LONG   0x10 0x00300020

END

// part3
OUTER_SET off_part3 = 0x775a84
OUTER_SET len_part3 = 0x14

COPY "bgmain.exe" "bgmain.exe"
	READ_ASCII off_part1 current_part1 ELSE 0 (len_part1)
	READ_ASCII off_part2 current_part2 ELSE 0 (len_part2)
	REAC_ASCII off_part3 current_part3 ELSE 0 (len_part3)
	PATCH_IF ("%current_part1%" STRING_EQUAL "%orig_part1%")
		 AND ("%current_part2%" STRING_EQUAL "%orig_part2%")
		 AND ("%current_part3%" STRING_EQUAL "%orig_part2%")
	THEN BEGIN
		WRITE_ASCIIE off_part1 "%patch_part1%" (len_part1)
		WRITE_ASCIIE off_part2 "%patch_part2%" (len_part2)
		WRITE_ASCIIE off_part3 "%patch_part2%" (len_part2)
   END ELSE PATCH_PRINT "Target bytes don't match. No changes made to executable."
BUT_ONLY

Note: I did not test that or even check the numeric values, so you may need to mess with it a bit. Also, since your 3rd patch appears identical to your 2nd, I did not define a patch for that but just rerouted it to the 2nd to shorten the code.

[Sam.]

Thanks for the help Miloch!!!

Note: I did not test that or even check the numeric values, so you may need to mess with it a bit. Also, since your 3rd patch appears identical to your 2nd, I did not define a patch for that but just rerouted it to the 2nd to shorten the code.

When I ran the code as is, I got a parse error:

[VERSION CHANGER.TP2] PARSE ERROR at line 52 column 1-24
Near Text: off_part3
GLR parse error

[VERSION CHANGER.TP2] ERROR at line 52 column 1-24
Near Text: off_part3
Parsing.Parse_error
ERROR: parsing [VERSION CHANGER.TP2]: Parsing.Parse_error
ERROR: problem parsing TP file [VERSION CHANGER.TP2]: Parsing.Parse_error

FATAL ERROR: Parsing.Parse_error

and I determined that I actually only needed steps 1 and 3 to change the version, so I tried removing step 2 to get:

// part1
OUTER_SET off_part1 = 0x7759cc
OUTER_SET len_part1 = 0xa
OUTER_PATCH_SAVE orig_part1 "" BEGIN
	INSERT_BYTES 0x00 len_part1
	WRITE_LONG   0x00 0x00360032
	WRITE_LONG   0x04 0x00390034
	WRITE_SHORT  0x08 0x0038
END

OUTER_PATCH_SAVE patch_part1 "" BEGIN
	INSERT_BYTES 0x00 len_part1
	WRITE_LONG   0x00 0x002e0030
	WRITE_LONG   0x04 0x00300035
	WRITE_LONG   0x08 0x0000
END

// part2
OUTER_SET off_part2 = 0x775a84
OUTER_SET len_part2 = 0x14
OUTER_PATCH_SAVE orig_part2 "" BEGIN
	INSERT_BYTES 0x00 len_part2
	WRITE_LONG   0x00 0x002c0032
	WRITE_LONG   0x04 0x00350020
	WRITE_LONG   0x08 0x0020002c
	WRITE_LONG   0x0c 0x002c0030
	WRITE_LONG   0x10 0x00320020
END

OUTER_PATCH_SAVE patch_part2 "" BEGIN
	INSERT_BYTES 0x00 len_part2
	WRITE_LONG   0x00 0x002c0030
	WRITE_LONG   0x04 0x00300020
	WRITE_LONG   0x08 0x0020002c
	WRITE_LONG   0x0c 0x002c0030
	WRITE_LONG   0x10 0x00300020

END

// patching
COPY "bgmain.exe" "bgmain.exe"
	READ_ASCII off_part1 current_part1 ELSE 0 (len_part1)
	READ_ASCII off_part2 current_part2 ELSE 0 (len_part2)
	PATCH_IF ("%current_part1%" STRING_EQUAL "%orig_part1%")
		 AND ("%current_part2%" STRING_EQUAL "%orig_part2%")
	THEN BEGIN
		WRITE_ASCIIE off_part1 "%patch_part1%" (len_part1)
		WRITE_ASCIIE off_part2 "%patch_part2%" (len_part2)
   END ELSE PATCH_PRINT "Target bytes don't match. No changes made to executable."
BUT_ONLY

which gives me this error:

Installing [Version Changer]
ERROR: illegal 4-byte write (____) offset 8 of 10-byte file INNER_PATCH_SAVE ""
Stopping installation because of error.

ERROR Installing [Version Changer], rolling back to previous state
[C:\Program Files\Black Isle\BGII - SoA\Version Changer Backup\backup/0/UNSETSTR.0] SET_STRING uninstall info not found
Will uninstall 0 files for [VERSION CHANGER.TP2] component 0.
Uninstalled 0 files for [VERSION CHANGER.TP2] component 0.
SETUP-CLASSICS049.TP2 0 0 Installed
SETUP-CLASSICS049.TP2 0 1 Installed
SETUP-CLASSICS049.TP2 0 2 Installed
SETUP-CLASSICS049.TP2 0 3 Installed
SETUP-CLASSICS049.TP2 0 4 Installed
SETUP-CLASSICS049.TP2 0 5 Installed
SETUP-CLASSICS049.TP2 0 6 Installed
SETUP-CLASSICS049.TP2 0 7 Installed
SETUP-CLASSICS049.TP2 0 8 Installed
VERSION TEST.TP2 0 0 Installed
ERROR: Failure("INNER_PATCH_SAVE \"\": write out of bounds")

What am I doing wrong?

[Qwinn]

You could try this. Download the attached file, save it somewhere, then do this:

INCLUDE ~wherever you saved the attached file.~

COPY ~BGMain.exe~ ~BGMain.exe~
  PATCH_PRINT ~Adjusting version code in engine.~

  SET searchlength = 0
  SET replacelength = 10
  SPRINT replacepattern ~1234567890~
  SPRINT replacebytes   ~30 00 2E 00 35 00 30 00 00 00~
  LAUNCH_PATCH_MACRO Q_Pattern_Maker
  WRITE_EVALUATED_ASCII 0x7759CC "%replacepattern%" (%replacelength%)
  PATCH_PRINT ~Engine Patched at Offset: 0x7759CC~

  SET searchlength = 0
  SET replacelength = 20
  SPRINT replacepattern ~12345678901234567890~
  SPRINT replacebytes   ~30 00 2C 00 20 00 30 00 2C 00 20 00 30 00 2C 00 20 00 30 00~
  LAUNCH_PATCH_MACRO Q_Pattern_Maker
  WRITE_EVALUATED_ASCII 0x775844 "%replacepattern%" (%replacelength%)
  PATCH_PRINT ~Engine Patched at Offset: 0x775844~
  WRITE_EVALUATED_ASCII 0x775A84 "%replacepattern%" (%replacelength%)
  PATCH_PRINT ~Engine Patched at Offset: 0x775A84~

BUT_ONLY_IF_IT_CHANGES

Aren't there multiple versions of BGMain.exe with different offsets though?

I wrote this macro and use it in my PS:T mods. Ghostdog also uses it for his UI mods, I believe, and Drog uses it for his Arcanum patches over at the Codex. It would also have the ability to search for a particular sequence of bytes (that feature is turned off in the above code, since you gave explicit offsets) and replace that way, which allows you to support multiple versions of bgmain.exe where the byte sequences to be replaced are at relatively similar but not identical offsets.

Qwinn

Attached Files

•  Q_EnginePatcher.tph   3.57K   258 downloads

Edited by Qwinn, 03 June 2009 - 07:51 AM.

[Sam.]

You could try this. Download the attached file, save it somewhere, then do this:

I wrote this macro and use it in my PS:T mods. Ghostdog also uses it for his UI mods, I believe, and Drog uses it for his Arcanum patches over at the Codex. It would also have the ability to search for a particular sequence of bytes (that feature is turned off in the above code, since you gave explicit offsets) and replace that way, which allows you to support multiple versions of bgmain.exe where the byte sequences to be replaced are at relatively similar but not identical offsets.

Qwinn

Hey, that worked great! Thanks!

Aren't there multiple versions of BGMain.exe with different offsets though?

Hadn't really thought about that....

[Miloch]

ERROR: illegal 4-byte write (____) offset 8 of 10-byte file INNER_PATCH_SAVE ""
Stopping installation because of error.

That should've been a WRITE_SHORT in the last part of patch_part1. While useful, Qwinn's macro is perhaps more code than you need. Also, since CA probably requires a patched ToB anyway, you want to be as precise as possible with an .exe patch, so the WHILE search loop isn't really desirable. I don't understand how that feature is "turned off" in the macro - it looks active (not commented out) to me.

[Qwinn]

Miloch, I'm not even running the search/replace macro in those examples. The Q_Engine_Patcher macro is never even called. For such limited use and writing to a specific offset, I'm just running the Q_Pattern_Maker which turns the replacebytes string into an actual sequence of the specified bytes (which overwrites the replacepattern). Specifying the searchlength as 0 tells Q_Pattern_Maker to skip converting searchbytes (which I don't even provide), and just convert the replacebytes.

As for being a lot of code, about 70% of the EnginePatcher macro is devoted to the single purpose of displaying the offset being patched in hexidecimal for the DEBUG file.

In terms of different versions of BGMain.exe, what I was referring to was different language versions. I thought different language versions of BGMain.exe were different sizes from the english version, TOB-patched or not.

Qwinn

Edited by Qwinn, 03 June 2009 - 11:00 AM.

[Miloch]

The Q_Engine_Patcher macro is never even called.

Oh, ok. What does this do, exactly:

PATCH_IF byte1 >= 48 AND byte1 <= 57 THEN BEGIN SET byte1 = (byte1 - 48) * 16 END ELSE BEGIN SET byte1 =(byte1 - 55) * 16 END
PATCH_IF byte2 >= 48 AND byte2 <= 57 THEN BEGIN SET byte2 = (byte2 - 48)	  END ELSE BEGIN SET byte2 =(byte2 - 55)	  END

As to different language versions, I am not sure, though that may be a valid point.

(Incidentally, do you always post first and edit/repost later? )

[Qwinn]

Usually

That bit converts ASCII characters in the searchbytes or replacebytes string into an actual byte representing those values.

So, if in my replacebytes, I have the characters ~2A~, that bit will convert it into an actual byte 0x2A and put it in the next byte of the replacepattern.

Qwinn

[Miloch]

That bit converts ASCII characters in the searchbytes or replacebytes string into an actual byte representing those values.

Oh. Is that even necessary, or is it more of a safety feature? Taimon's code above seems to work without doing that.

[Qwinn]

Oh. Is that even necessary, or is it more of a safety feature? Taimon's code above seems to work without doing that.

It's far more convenient and user-friendly. To make up his string, you divided the replace strings up into 4 byte WRITE_LONGs, reverse them, concatenated them together, puts it all in an OUTER_PATCH string.

Sam. asked us to write this byte sequence at the offset:

30 00 2E 00 35 00 30 00 00 00

Your method required creating a string with those byte values by doing this:

OUTER_SET len_part1 = 0xa
	OUTER_PATCH_SAVE patch_part1 "" BEGIN
	INSERT_BYTES 0x00 len_part1
	WRITE_LONG   0x00 0x002e0030
	WRITE_LONG   0x04 0x00300035
	WRITE_LONG   0x08 0x0000
END

Rather gruesome, especially if you are handed really really long byte patches. On the other hand, all I had to do was:

SET replacelength = 10
  SPRINT replacepattern ~1234567890~
  SPRINT replacebytes   ~30 00 2E 00 35 00 30 00 00 00~

...and run my macro.

In PS:T, scient has handed me some 300-byte long patches. I'd rather be shot than do it with 75 WRITE_LONGs that have to reverse the order of each and every one of the 300 bytes. My method can handle all that with much smaller chance of error (because I didn't even have to touch the pattern he gave me, just cut and paste it) with exactly the same number of lines of code and effort as a 2 byte patch.

Qwinn

Edited by Qwinn, 03 June 2009 - 12:21 PM.

[Miloch]

In PS:T, scient has handed me some 300-byte long patches. I'd rather be shot than do it with 75 WRITE_LONGs that have to reverse the order of each and every one of the 300 bytes.

I see. Yes, that is more convenient then for long writes, though perhaps not so much for doing single-byte writes all over the place.

[Qwinn]

Well, sure, there is no programmatic way to handle this that can't be potentially simplified by just doing a single WRITE_BYTE command.

On the other hand, with my experience, I can tell you that one byte rarely suffices. It happens sometimes, and it's a cause for celebration when that's all it takes, but its not the norm.

The example I gave was actually the -shorter- of the strings that Sam. needed. You gotta admit torturing that 20 byte string into the WRITE_LONGs was a pain enough all by itself, no? With tons of room for human error? (which in fact happened?)

You could hand me 20 search/replace strings to do in the engine - of ANY length - and I could set them all up and actually accurate and functional inside an hour. And able to patch either the 2CD or 4CD version of PS:T, each of which has different offsets for the same functions. I know, cause I've done it, multiple times. I don't think that's possible with the WRITE_LONG method even if you were dealing with just 10 and 20 byte strings.

What we need to do now is confirm whether there are multiple versions of bgmain.exe out there that need to be accounted for. I'm fairly sure there are. But PS:T is my playground, BG2 is the forte of others, and I will let someone else determine it for sure. Once that's determined, I'll show how my macro can be set up so that it identifies which version is being used and patches it correctly accordingly.

Qwinn

Edited by Qwinn, 03 June 2009 - 12:46 PM.

[Miloch]

On the other hand, with my experience, I can tell you that one byte rarely suffices. It happens sometimes, and it's a cause for celebration when that's all it takes, but its not the norm.

What I said was a bunch of single-byte writes all over the place, as for example with Erephine's patch (for which you suggested this macro).

Ninja edit before you can get off a response : Though PHP_EACH might possibly simplify that.

Edited by Miloch, 03 June 2009 - 01:02 PM.

[Qwinn]

Ninja edit all you like I'd be the biggest hypocrite in the world to give anyone grief for it, that's basically my SOP.

If I'm understanding what's being undertaken with Erephine's mod, they may be -small- patches but they won't be single-byte. But even more importantly... the replace string may well be a single byte or a handful, but a unique search string when the precise offset can't be known most certainly won't be.

Incidentally, a quick google found me this. It's part of the BGT documentation, and seems fairly sure evidence that, indeed, at least some foreign language versions have different offsets.

The data pertaining to the starting XP is contained in the executable file BGMain.exe. So far, it is known that in all English, German, and Chinese languages, the starting XP hex offset is 0x6B7258. However, in Polish languages, the starting XP hex offset is 0x6B6270. The patching of BGMain.exe is handled by Setup-BGT.tp2. The code dynamically detects any long (64-bit) value that is bounded by a previous long value of 0 and a succeeding long value of 161000 in the hex offset range 0x6B0000 to 0x6C0000. This may not ensure that all versions of BGMain.exe are patched correctly, but empirical tests have shown that this method works so far with most versions of Throne of Bhaal.

At any rate, an install method that can handle different offsets may well make it easy to make an SOA compatible version, instead of forcing a TOB install, for whatever that's worth.

Qwinn

Edited by Qwinn, 03 June 2009 - 01:24 PM.

[Miloch]

If I'm understanding what's being undertaken with Erephine's mod, they may be -small- patches but they won't be single-byte.

You may be right. I don't know why she did it as a bunch of WRITE_BYTEs since it appears a good deal of it could be consolidated into consecutive stretches.

[Sam.]

Wow, I wish I was smart enough to be in this conversation....

The data pertaining to the starting XP is contained in the executable file BGMain.exe. So far, it is known that in all English, German, and Chinese languages, the starting XP hex offset is 0x6B7258. However, in Polish languages, the starting XP hex offset is 0x6B6270. The patching of BGMain.exe is handled by Setup-BGT.tp2. The code dynamically detects any long (64-bit) value that is bounded by a previous long value of 0 and a succeeding long value of 161000 in the hex offset range 0x6B0000 to 0x6C0000. This may not ensure that all versions of BGMain.exe are patched correctly, but empirical tests have shown that this method works so far with most versions of Throne of Bhaal.

Well, everything should always be after 0x770000. As far as finding a unique pattern that doesn't change with the various languages..., I'm not really sure. With the initial install of Classic Adventures, the value would be changed from 26498 to 0.50, but if you change the version for each of the patches, it would then go to 0.50a, 0.50b, etc., so you couldn't just keep the same search for the value. And while the 26498 is always proceeded by "PrivateBuild" (in any English version anyway), this would probably change with the language....

And if this makes it more convenient:

Edited by Sam., 03 June 2009 - 05:10 PM.

[AnnabelleRose]

If I remember correctly, Bioware said we could mod the game as much as we wanted, as long as we did not hack the BGMain.exe file.


I mentioned it on another discussion post at CoM a few days ago, and Sola backed my memory on what Bioware wanted/did not want.

Not sure if they are still picky about it though, that was several years ago.

[Miloch]

I mentioned it on another discussion post at CoM a few days ago, and Sola backed my memory on what Bioware wanted/did not want.

Indeed, and I had already linked your post here, but I also commented on why it's not terribly relevant or enforceable anymore, if it ever was (in summary, both fair-use and reverse-engineering laws would permit this rather than prohibit it, especially since it is for nonprofit/research purposes).

[AnnabelleRose]

This is what happens when MTS quickly scans posts at work.

Sorry about that, ignore me.