Rebuilding Blucher's alternate BG2 NPCs

Nythrun · March 13, 2007

Eff conversion by itself, if anyone wants (should have posted this before, so busy though )

COPY_EXISTING_REGEXP GLOB ~^[^ .][^ .]?[^ .]?[^ .]?[^ .]?[^ .]?[^ .]?[^ .]?\.cre$~ ~override~
 PATCH_IF ((SOURCE_SIZE > 0x2d3) AND (~%SOURCE_RES%~ STRING_COMPARE_CASE ~CHARBASE~)) THEN BEGIN
READ_BYTE	0x0033 "fj_eff" ELSE 0x1
PATCH_IF ("fj_eff" = 0x0) THEN BEGIN
  WRITE_BYTE 0x0033 0x1
  READ_LONG  0x02c4 "fj_elo" ELSE 0x0
  READ_LONG  0x02c8 "fj_elc" ELSE 0x0
  PATCH_IF ("fj_elc" > 0x0) THEN BEGIN
	PATCH_FOR_EACH "fj_of1" IN 0x02a0 0x02a8 0x02b0 0x02b8 0x02bc BEGIN
	  READ_LONG  "fj_of1" "fj_of2"
	  WRITE_LONG "fj_of1" (("fj_of2" >= "fj_elo") ? ("fj_of2" + ("fj_elc" * (0x108 - 0x30))) : "fj_of2")
	END
	READ_ASCII   "fj_elo" ~fj_efx~ (0x30 * "fj_elc")
	DELETE_BYTES "fj_elo" (0x030 * "fj_elc")
	INSERT_BYTES "fj_elo" (0x108 * "fj_elc")
	SPRINT ~fj_rfx~ ~~
	INNER_PATCH ~%fj_efx%~ BEGIN
	  FOR ("i1" = 0x0; "i1" < "fj_elc"; "i1" += 0x1) BEGIN
		READ_SHORT	 (("i1" * 0x30) + 0x00) "fj_opc"
		READ_BYTE	  (("i1" * 0x30) + 0x02) "fj_tar"
		READ_BYTE	  (("i1" * 0x30) + 0x03) "fj_pow"
		READ_LONG	  (("i1" * 0x30) + 0x04) "fj_pa1"
		READ_LONG	  (("i1" * 0x30) + 0x08) "fj_pa2"
		READ_BYTE	  (("i1" * 0x30) + 0x0c) "fj_tim"
		READ_BYTE	  (("i1" * 0x30) + 0x0d) "fj_dis"
		READ_LONG	  (("i1" * 0x30) + 0x0e) "fj_dur"
		READ_BYTE	  (("i1" * 0x30) + 0x12) "fj_pr1"
		READ_BYTE	  (("i1" * 0x30) + 0x13) "fj_pr2"
		READ_ASCII	 (("i1" * 0x30) + 0x14) ~fj_res~
		INNER_PATCH_SAVE ~fj_rfx~ ~%fj_rfx%~ BEGIN
		  INSERT_BYTES (("i1" * 0x108) + 0x00) 0x110
		  WRITE_LONG   (("i1" * 0x108) + 0x10) "fj_opc"
		  WRITE_LONG   (("i1" * 0x108) + 0x14) "fj_tar"
		  WRITE_LONG   (("i1" * 0x108) + 0x18) "fj_pow"
		  WRITE_LONG   (("i1" * 0x108) + 0x1c) "fj_pa1"
		  WRITE_LONG   (("i1" * 0x108) + 0x20) "fj_pa2"
		  WRITE_BYTE   (("i1" * 0x108) + 0x24) "fj_tim"
		  WRITE_LONG   (("i1" * 0x108) + 0x28) "fj_dur"
		  WRITE_SHORT  (("i1" * 0x108) + 0x2c) "fj_pr1"
		  WRITE_SHORT  (("i1" * 0x108) + 0x2e) "fj_pr2"
		  WRITE_ASCIIE (("i1" * 0x108) + 0x30) ~%fj_res%~
		  WRITE_BYTE   (("i1" * 0x108) + 0x5c) "fj_dis"
		  WRITE_LONG   (("i1" * 0x108) + 0x80) 0xffffffff
		  WRITE_LONG   (("i1" * 0x108) + 0x84) 0xffffffff
		  WRITE_LONG   (("i1" * 0x108) + 0x88) 0xffffffff
		  WRITE_LONG   (("i1" * 0x108) + 0x8c) 0xffffffff
		  WRITE_LONG   (("i1" * 0x108) + 0xa4) 0xffffffff
		  DELETE_BYTES (("i1" * 0x108) + 0x08) 0x8
		END
	  END
	END
	WRITE_ASCIIE "fj_elo" ~%fj_rfx%~
  END
END
 END
BUT_ONLY

pro5 · March 15, 2007

So, the purpose of code above is to change all CRE eff structures to v1? If so, I may have use for it.

Is there any practical difference between

COPY_EXISTING_REGEXP GLOB ~^[^ .][^ .]?[^ .]?[^ .]?[^ .]?[^ .]?[^ .]?[^ .]?\.cre$~

and simply

COPY_EXISTING_REGEXP GLOB ~.*\.cre~

?

Nythrun · March 15, 2007

To change them to version 2, rather - the 0x108 byte length structure that BG2 supports that BG1 didn't, that allows fully functional LOCALS and variable setting via opcode and spell effect by primary/secondary type and all that good stuff

If youwant to go the other way, it'd be

COPY_EXISTING_REGEXP GLOB ~^[^ .][^ .]?[^ .]?[^ .]?[^ .]?[^ .]?[^ .]?[^ .]?\.cre$~ ~override~
 PATCH_IF ((SOURCE_SIZE > 0x2d3) AND (~%SOURCE_RES%~ STRING_COMPARE_CASE ~CHARBASE~)) THEN BEGIN
READ_BYTE	0x0033 "eff_type" ELSE 0x0
PATCH_IF ("eff_type" = 0x1) THEN BEGIN
  WRITE_BYTE 0x0033 0x0
  READ_LONG  0x02c4 "elo"
  READ_LONG  0x02c8 "elc"
  PATCH_IF ("elc" > 0x0) THEN BEGIN
	PATCH_FOR_EACH "off1" IN 0x02a0 0x02a8 0x02b0 0x02b8 0x02bc BEGIN
	  READ_LONG  "off1" "off2"
	  WRITE_LONG "off1" (("off2" >= "elo") ? ("off2" + ("elc" * (0x30 - 0x108))) : "off2")
	END
	READ_ASCII   "elo" ~efx~ (0x108 * "elc")
	DELETE_BYTES "elo" (0x108 * "elc")
	INSERT_BYTES "elo" (0x030 * "elc")
	SPRINT ~rfx~ ~~
	INNER_PATCH ~%efx%~ BEGIN
	  FOR ("i1" = 0x0; "i1" < "elc"; "i1" += 0x1) BEGIN
		READ_LONG  (("i1" * 0x108) + 0x08) "opcode"
		READ_LONG  (("i1" * 0x108) + 0x0c) "target"
		READ_LONG  (("i1" * 0x108) + 0x10) "power"
		READ_LONG  (("i1" * 0x108) + 0x14) "parameter1"
		READ_LONG  (("i1" * 0x108) + 0x18) "parameter2"
		READ_BYTE  (("i1" * 0x108) + 0x1c) "timing_mode"
		READ_LONG  (("i1" * 0x108) + 0x20) "duration"
		READ_SHORT (("i1" * 0x108) + 0x24) "probability1"
		READ_SHORT (("i1" * 0x108) + 0x26) "probability2"
		READ_ASCII (("i1" * 0x108) + 0x28) ~resref~
		READ_BYTE  (("i1" * 0x108) + 0x54) "dispellability"
		INNER_PATCH_SAVE ~rfx~ ~%rfx%~ BEGIN
		  INSERT_BYTES (("i1" * 0x30) + 0x00) 0x30
		  WRITE_SHORT  (("i1" * 0x30) + 0x00) "opcode"
		  WRITE_BYTE   (("i1" * 0x30) + 0x02) "target"
		  WRITE_BYTE   (("i1" * 0x30) + 0x03) "power"
		  WRITE_LONG   (("i1" * 0x30) + 0x04) "parameter1"
		  WRITE_LONG   (("i1" * 0x30) + 0x08) "parameter2"
		  WRITE_BYTE   (("i1" * 0x30) + 0x0c) "timing_mode"
		  WRITE_BYTE   (("i1" * 0x30) + 0x0d) "dispellability"
		  WRITE_LONG   (("i1" * 0x30) + 0x0e) "duration"
		  WRITE_BYTE   (("i1" * 0x30) + 0x12) "probability1"
		  WRITE_BYTE   (("i1" * 0x30) + 0x13) "probability2"
		  WRITE_ASCIIE (("i1" * 0x30) + 0x14) ~%resref%~
		END
	  END
	END
	WRITE_ASCIIE "elo" ~%rfx%~
  END
END
 END
BUT_ONLY

double check my arithmetic, please

~.*\.cre matches .cre (which we don't want, as that's invalid). The bracing ^ and $ are just to indicate the beginning and end of the expression, and I'm using [^ .] to match any character that's not a space, period, or newline rather than . which matches any character except newline because spaces or other periods shouldn't be in filenames.

So in short, there's no practical difference, I just have OCD

pro5 · March 15, 2007

Yes, I meant version 2 - was just looking at the 0x33 offset field value. Thanks!

PATCH_IF ("eff_type" = 0x0) THEN BEGIN
WRITE_BYTE 0x0033 0x1

If downgrading to v1, perhaps this should rather read

	PATCH_IF ("eff_type" = 0x1) THEN BEGIN
  WRITE_BYTE 0x0033 0x0

Nythrun · March 15, 2007

Absolutely, yes

cmorgan · March 16, 2007

I understand this code can be used to repair on all .cres in a Tutu/EasyTutu install to use .eff v2.

As I understand it, this is preferable because the BG2 engine is designed to use .eff v2, most notably some LOCALS variables could be truncated.

BGT .cres use v2 (I believe).

A person installing LNythrun's Level 1 NPC's will have the relevant NPCs corrected to use eff v2.

(I may have asked before, perhaps even in this thread...)

Before I steal this and put it in a LIB to run if a Tutu/EasyTutu install is detected, three questions, please.

Is this code set to be included in TutuFix or BG2 Tweaks (BG2 Fixpack should not be run on or before EasyTutu)?
It looks like it does, but to make sure I read this right, does this code retain current .eff info, so that it can be run on already modded .cres (which would happen if it ran through a LIB in The BG1 NPC Project)?
Does this interact at all with weapon proficiencies, and where should I be researching this?

Nythrun · March 16, 2007

It should be okay to borrow as it is, sure - I did go back and prefix the variables just in case anyone wants to run this in tandem with other macros, but that's most likely cosmetic.

Any existing on-creature embedded effects are converted to version two, but they're retained rather than discarded

It doesn't interact with BG1 on-cre weapon proficiencies at all, as those aren't effects. BG2 proficiencies will be converted to version two effect structure if they're not already. That probably isn't answering your question very well, is it?

cmorgan · March 16, 2007

It answers well enough... it means that this is not install-order dependent, should be ok to add into BG1 NPC as a fix, and I will do so

The only remaining thing is to see if Macready and/or CamDawg want it for TutuFix or BG1 Fixpack.

Nythrun · April 16, 2007

Got the druid kit proficiency mess sorted today for release. Still need to run a test with Sorcerer and Monk kits (I suppose I'll have to make some - there aren't any?) to make sure that bit works.

Kinda holding off on a final release, because I've the sinking feeling that once I do so, game-crashing bugs will swarm out of nowhere and spoil everyone's install. Give it another week, I suppose

Miloch · April 17, 2007

If you hit [Q] and install didn't quit, it's nothing I've done or can fix. I'll see about replicating this, but if there's a bug there it's in a section of WeiDU that the Bigg won't have an easy time fixing.
Bad WeiDU! Actually, I was thinking the previous glitch with the berserker assignment to PCs is what threw this for a loop. But that's just idle speculation I guess. I'm just a barbarian... it's well beyond my skill to try to dig through your killer code or figure out how WeiDU is or isn't supposed to work.

It looks like there's confirmation of this glitch in at least a couple other mods:

But it seems that uninstalling mods in the middle of an install corrupts installation (here, and one fellow French player confirmed by PM that (s)he has got the same problem). Furthermore, I have already reported another severe bug in WeiDU while uninstall mods and using the [Q]uit prompt.
I think there is a WeiDU problem with this. I know that uninstalling middle components and re-installing them in BG1UB for Tutu causes install-breaking problems with WeiDU.

All I know is it hosed my installation of this mod rather severely.

Nythrun · April 17, 2007

Uninstall has been flaky forever, yeah. If Bigg decides to trash the whole tpinst.ml and rebuild it for version 200 that make take care of it. No way will this component be undeprecated unless he does though - the only other way I can think of to do this would involve picking your kit from a dialogue in game - which is meta, meta, meta.

April 18, 2007

I've got a problem, it seems I can't change Khalid. The error says that there was not a BGKhalid.cre file to be copied.

I know he is easy to overlook but all the other kids get to play and then he should too

April 19, 2007

I've got a problem, it seems I can't change Khalid. The error says that there was not a BGKhalid.cre file to be copied.

I know he is easy to overlook but all the other kids get to play and then he should too

And I also got a problem with Jaheira, I tried to change her into Fighter/Totemic Druid but she stays Fighter/Druid, haven't tried to change her into anything else though so I don't know if its only the kits that doesn't work there.

Kulyok · July 14, 2007

I think it might be lvl1npc/xptweak: after I talked to Jaheira about joining, Khalid didn't join, only Jaheira did. (Since I had "NPCs go to an inn" component of BG1 NPC, though, I just let Jaheira go, and then offered her to join again: this time both joined).

Also: Coran, upon joining(and after the script worked), was level 3/level 3, though his XP was 630/630 for each class, just about mine.

berelinde · July 30, 2007

Just wanted to point out something inconvenient in a BGT installation. This mod does nothing to those NPCs affected by SCS, however SCS only affects NPCs when they are recruited in BG1. BGT offers the possibility of starting a game at the beginning of SoA. Thing is, when you do start an SoA game, you're stuck with vanilla classes and kits, since SCS doesn't touch BG2. Grrrr.

Sign In

Rebuilding Blucher's alternate BG2 NPCs

Recommended Posts

Nythrun

Link to comment

pro5

Link to comment

Nythrun

Link to comment

pro5

Link to comment

Nythrun

Link to comment

cmorgan

Link to comment

Nythrun

Link to comment

cmorgan

Link to comment

Nythrun

Link to comment

Miloch

Link to comment

Nythrun

Link to comment

Guest Guest

Link to comment

Guest Nitho

Link to comment

Kulyok

Link to comment

berelinde

Link to comment

Archived

Website

Forums

My Activity Streams

Downloads

Gallery