83 replies to this topic

[Turambar]

As Miloch suggested me, I'll post here any contribution for the next version.

I'll also post a question about the BP skeleton warriors: I've noticed that the BP skeletons receive some spells; in v180a, only 2 or 3 .cre s are patched, though.
As there are much more .cre files corresponding to skeleton warriors, will you patch all of them or is there a reason to only patch those?

What about the skeleton warriors from BG1 imported by BGT (bgskelwa)? And I think that you could patch the skellord from DS: they are improved skelwas, so they should be patched as well?

Anyway, I've started with the Xvart village, where the main problem was to avoid DS and BP overwriting each other.
 xvartv.tp2   1.26K   411 downloads
This component should now only copy cres and scripts if they don't exist yet.
Moreover, if the main component is not installed, they get valid vanilla scripts
Just a question: I've copied this from DS:

EXTEND_BOTTOM ~AR3498.BCS~ ~BPv180/XVART/AR3498.BAF~

If AR3498.bcs does not exist yet, will it be created, or will there be an error?

Following strings should be added:
@1002 = ~This component has already been installed with DSotSC~
@1003 = ~This component requires BGT~
@1004 = ~xvart shaman~

Without having to ask anyone else, I'll also post the Italian version:
@1002 = ~Questo componente è già stato installato con DSotSC~
@1003 = ~Questo componente richiede BGT~
@1004 = ~Sciamano xvart~

Edited by Turambar, 26 September 2010 - 01:47 PM.

[Miloch]

What about the skeleton warriors from BG1 imported by BGT (bgskelwa)? And I think that you could patch the skellord from DS: they are improved skelwas, so they should be patched as well?

I think horred would have to answer the "why" but I suspect it's because BP was developed mainly for BG2 or BGT plus the big megamods, so it doesn't explicitly include BG1 creatures. But I think horred said somewhere he would be open to supporting them, so I don't think it's a problem if you want to add them.

If AR3498.bcs does not exist yet, will it be created

Yes.

Oh, and you don't need to look at the Shade Lord component - I revised that a while ago (before even the main component I think).

[Turambar]

I'm working on the level50 rules now - the code was quite messy, with lots of inner actions, copy +s,..., which I think should be used only if necessary.
Moreover, I've noticed that some kit tables were already messed up in the original game, so what I'm writing should also fill in those gaps; it should also skip files which are already up to level 50.

I should have finished the functions; now, I still have to write, for the single kits, the instructions which should add AP_s and GA_s .

Is there any equivalent of COPY_EXISTING_REGEXP for the APPEND_COL command?

I mean, a way to append to all CLAB.* s the same thing

Edited by Turambar, 29 September 2010 - 08:12 AM.

[Mike1072]

Moreover, I've noticed that some kit tables were already messed up in the original game, so what I'm writing should also fill in those gaps

What problems did you find?

I should have finished the functions; now, I still have to write, for the single kits, the instructions which should add AP_s and GA_s .

Is there any equivalent of COPY_EXISTING_REGEXP for the APPEND_COL command?

I mean, a way to append to all CLAB.* s the same thing

Be careful - APPEND_COL will fail if your data doesn't have the same number of rows as the file does, and CLAB files can have any number of rows. You could try something like this:

ACTION_FOR_EACH file IN clabba01 clabba02 clabba03 clabba04 BEGIN
	COPY_EXISTING - ~%file%.2da~ ~override~
		COUNT_2DA_COLS num_cols
 		COUNT_2DA_ROWS num_cols num_rows

	// determine what level the file goes up to, whether your data needs additional **** entries to match the number of ABILITY rows in the file, or whether the file needs additional ABILITY rows to match the amount of entries you're adding in a single column

	// then do your APPEND_COLs
END

Edited by Mike1072, 29 September 2010 - 01:43 PM.

[Turambar]

Moreover, I've noticed that some kit tables were already messed up in the original game, so what I'm writing should also fill in those gaps

What problems did you find?

One fighter table had a missing entry for level 40; another table had some 5 columns too much, on one row only, and I don't know what other mods could do.

I should have finished the functions; now, I still have to write, for the single kits, the instructions which should add AP_s and GA_s .

Is there any equivalent of COPY_EXISTING_REGEXP for the APPEND_COL command?

I mean, a way to append to all CLAB.* s the same thing

Be careful - APPEND_COL will fail if your data doesn't have the same number of rows as the file does, and CLAB files can have any number of rows. You could try something like this:

ACTION_FOR_EACH file IN clabba01 clabba02 clabba03 clabba04 BEGIN
	COPY_EXISTING - ~%file%.2da~ ~override~
		COUNT_2DA_COLS num_cols
 		COUNT_2DA_ROWS num_cols num_rows

	// determine what level the file goes up to, whether your data needs additional **** entries to match the number of ABILITY rows in the file, or whether the file needs additional ABILITY rows to match the amount of entries you're adding in a single column

	// then do your APPEND_COLs
END

I did something like that, to count the rows. What I was thinking of was to patch all CLAB files, without having to list them all, in order to include any coming from other mods as well (at least, giving them all enough columns)

[Mike1072]

What I was thinking of was to patch all CLAB files, without having to list them all, in order to include any coming from other mods as well (at least, giving them all enough columns)

Ah, okay. If you don't have any specific data to add, it might even be easier. You'll want to scan kitlist.2da to get a list of all kits' CLAB files (use an array). Once you have the list, you can go through it and append new columns to those files.

Edit: BG2 Tweaks does this in its Remove XP Cap component.

Edited by Mike1072, 29 September 2010 - 05:12 PM.

[Miloch]

Is there any equivalent of COPY_EXISTING_REGEXP for the APPEND_COL command?

I mean, a way to append to all CLAB.* s the same thing

Just cover all of them in a fat ACTION_FOR_EACH statement. Anytime you patch a known, finite list of files, it's going to be quicker and more efficient than regexp (at least on a typical megamod install) even if it's several hundred or thousand files. So, e.g.:

ACTION_FOR_EACH clab IN ~clabwa01~ ~clabwa02~ ~clabwa03~ ... BEGIN
  ACTION_IF FILE_EXISTS_IN_GAME ~%clab%.2da~ BEGIN
    APPEND_COL ~%clab%.2da~ whatever UNLESS whatever
  END
END

I don't know why you'd need to scan kitlist.2da on every install - just grab a full list from a BWP expert install. Unless folks are actively adding new clab files but hmm, I doubt it and anyway you can always update it. If a file isn't on a particular install, it'll get skipped due to the FILE_EXISTS_IN_GAME. But you do want to account for the existing number of columns which can be out-of-whack, as you've seen for tooltip.2da. There is code in Thrown Hammers that deals with that and pads accordingly any missing column entries before adding new ones.

[DavidWallace]

I don't know why you'd need to scan kitlist.2da on every install - just grab a full list from a BWP expert install. Unless folks are actively adding new clab files but hmm, I doubt it and anyway you can always update it.

I don't myself agree with this philosophy:
(i) It's not a good idea in any software environment to require components to actively have to be updated (more than you can help) when other components are changed. It's doubly not a good idea in our community, where a mod might very well not be updated on any kind of frequent basis.
(ii) The logical structure of the code is a great deal more clear on the kitlist.2da philosophy. What you want the code to do is to modify all kit files, not to modify a fixed list which is intended to be the same as all kit files. Code that wears its purpose on its sleeve is a lot easier to debug and maintain.
(iii) reading in kitlist.2da takes a small fraction of a second.

[Miloch]

I don't myself agree with this philosophy

I don't think I was espousing a "philosophy" - at least not with that statement. If there's any generalisation to be drawn from my remarks, it'd be more along these lines:

Anytime you patch a known, finite list of files, it's going to be quicker and more efficient than regexp (at least on a typical megamod install)

(Feel free to dispute that empirically, if you're so inclined, but my experience with regexp is that it's incredibly time-consuming late in a megamod install, particularly on a slower hard drive.)

As for reading in a list of files from another file, I see now that amounts to much the same thing as what I was proposing, and yes, is probably more efficient. Anyhow, it's not using regexp, is still patching a finite list of files, and you'd still probably be constructing an ACTION_FOR_EACH or similar loop to handle each file in that list.

[DavidWallace]

I don't myself agree with this philosophy

I don't think I was espousing a "philosophy" - at least not with that statement. If there's any generalisation to be drawn from my remarks, it'd be more along these lines:

Anytime you patch a known, finite list of files, it's going to be quicker and more efficient than regexp (at least on a typical megamod install)

(Feel free to dispute that empirically, if you're so inclined, but my experience with regexp is that it's incredibly time-consuming late in a megamod install, particularly on a slower hard drive.)

No, I agree with that. And REGEXP is probably an example where logical clarity in the code can be outweighed by sheer length of install time. (Though it's very often unavoidable.)

[Turambar]

I've written a new code for level 50 rules, which removes all inner actions and copy +s and increases compatibility.
 level50.tp2   26.05K   514 downloads
What's new?
The old code only checked if two particular mods were installed, but there could be new mods with level 50 rules.
It only patches files which do not contain the level 50 rules (it uses an UNLESS condition for that; I've written the corresponding regexp to avoid skipping other files, if they contain number 50 anywhere else than in the row or column where the level is listed); moreover, it corrects any file which had too short or too long lines, and the resulting file should be very tidy, for any other mod.
My mod extends ALL existing clab files, reading them from kitlist.2dA although most of them are only padded with ****, and every mod should provide its own level50 rules. But I think that it's easyer, for other mods, if all clab files have the same size.

For .tra files: this component does not need strings from @445 to @499 anymore;
@444 should be changed so that it's like @442, but with ROT instead of TDD.

Could you please check if it works in your games, too? I'm pretty sure, but double checking is never enough!

[Miloch]

I will test it on BWP and unmodded BG2 but it might take me a while, so it will be good if other folks can test it.

What do you plan on looking at next? Just wondering because once I finish the spell-patching I could look at the REPLACE_BCS_BLOCK updates if you are going to keep looking at other subcomponents (oh and by Shade Lord I meant Crypt King, but actually I updated both since they're both addressed in different sections).

[Turambar]

I will test it on BWP and unmodded BG2 but it might take me a while, so it will be good if other folks can test it.

What do you plan on looking at next? Just wondering because once I finish the spell-patching I could look at the REPLACE_BCS_BLOCK updates if you are going to keep looking at other subcomponents (oh and by Shade Lord I meant Crypt King, but actually I updated both since they're both addressed in different sections).

In the version I'd posted yerserday, I had kept the original restrictions, which prevent this component from being installed if there are ROT or TDD.
Actually, as my code works, it should not create compatibility problems with any of those mods, so maybe it's better to remove the restriction, so that modded kits as well receive level 50 rules, as my code does.

here's the corrected version; You'll need the original BPv180a folder in the same game directory to install this.


Another thing... this component should be installed after most kits, as very few (tdd, all those from my twixpack) have a 50-columned CLAB table. In particular, chloe's kensai kit is patched just like the kensai kit


@Miloch: I'll go on working on extra components, if they're not too difficult. But I have to fix a compatibility problem in my twixpack first

Attached Files

•  level50.tp2   26.16K   344 downloads

Edited by Turambar, 22 January 2011 - 06:59 AM.

[Turambar]

I'll work on Improved Suldanesselar and those other components now, which apparently need to be fixed.
Have you done any others a part from the Crypt king and shadow lord?

The red dragon had no prefix in his name and his script was between the normal scripts; I've moved it to the 'suldan' folder and renamed it to BPSULDRA; anyway, I'll attach the new suldan folder together with the code. I'll also remove the are file, because it will be patched now.
You can also remove, from the language folders, the BPsiege[1-9].tra files, because they're all like BPsiege0.tra, and I'll use that one only.

I've also moved the scripts with names tAR28## to the SULDAN folder; if noone else needs them, You can remove them as well.
Also the script 'suscene5' should not be used by the main component (although the main component compiles it); it can be removed from new_baf folder as well as dragredd.baf
I've run the 'search unused files' tool of NI, and none of those two scripts is used by the main component

edit: here's the Suldanesselar code.

re-edit: something was missing (in the original code as well...)

//////////////////////SULDANESSALLAR///////////////////////////

BEGIN @375

//New triggers (10), maybe spawns too--Improved Suldanessallar
COPY_EXISTING ~ar2800.are~        ~override/ar2800.are~
	LAUNCH_PATCH_FUNCTION ADD_AREA_REGION_TRIGGER
		INT_VAR ab_RT_BbLX=583
				ab_RT_BbLY=879
				ab_RT_BbHX=593
				ab_RT_BbHY=888
				ab_RT_VxPr=5
				ab_RT_Itxt=0xffffffff
				ab_RT_TSet=1
				ab_RT_LPoX=588
				ab_RT_LPoY=883
				ab_RT_Vx_X_0=590
				ab_RT_Vx_Y_0=878
				ab_RT_Vx_X_1=583
				ab_RT_Vx_Y_1=879
				ab_RT_Vx_X_2=586
				ab_RT_Vx_Y_2=888
				ab_RT_Vx_X_3=593
				ab_RT_Vx_Y_3=886
				ab_RT_Vx_X_4=590
				ab_RT_Vx_Y_4=878
		STR_VAR ab_RT_Name=~Dragon0~
				ab_RT_Rbcs=~BPsiege0~
	END
	LAUNCH_PATCH_FUNCTION ADD_AREA_REGION_TRIGGER
		INT_VAR ab_RT_BbLX=906
				ab_RT_BbLY=1134
				ab_RT_BbHX=915
				ab_RT_BbHY=1143
				ab_RT_VxPr=5
				ab_RT_Itxt=0xffffffff
				ab_RT_TSet=1
				ab_RT_LPoX=910
				ab_RT_LPoY=1138
				ab_RT_Vx_X_0=914
				ab_RT_Vx_Y_0=1133
				ab_RT_Vx_X_1=906
				ab_RT_Vx_Y_1=1135
				ab_RT_Vx_X_2=909
				ab_RT_Vx_Y_2=1143
				ab_RT_Vx_X_3=915
				ab_RT_Vx_Y_3=1140
				ab_RT_Vx_X_4=914
				ab_RT_Vx_Y_4=1133
		STR_VAR ab_RT_Name=~Dragon1~
				ab_RT_Rbcs=~BPsiege1~
	END
	LAUNCH_PATCH_FUNCTION ADD_AREA_REGION_TRIGGER
		INT_VAR ab_RT_BbLX=2937
				ab_RT_BbLY=1032
				ab_RT_BbHX=2949
				ab_RT_BbHY=1041
				ab_RT_VxPr=5
				ab_RT_Itxt=0xffffffff
				ab_RT_TSet=1
				ab_RT_LPoX=2943
				ab_RT_LPoY=1036
				ab_RT_Vx_X_0=2947
				ab_RT_Vx_Y_0=1031
				ab_RT_Vx_X_1=2937
				ab_RT_Vx_Y_1=1033
				ab_RT_Vx_X_2=2942
				ab_RT_Vx_Y_2=1041
				ab_RT_Vx_X_3=2949
				ab_RT_Vx_Y_3=1038
				ab_RT_Vx_X_4=2947
				ab_RT_Vx_Y_4=1031
		STR_VAR ab_RT_Name=~Dragon2~
				ab_RT_Rbcs=~BPsiege2~
	END
	LAUNCH_PATCH_FUNCTION ADD_AREA_REGION_TRIGGER
		INT_VAR ab_RT_BbLX=3441
				ab_RT_BbLY=870
				ab_RT_BbHX=3451
				ab_RT_BbHY=878
				ab_RT_VxPr=5
				ab_RT_Itxt=0xffffffff
				ab_RT_TSet=1
				ab_RT_LPoX=3446
				ab_RT_LPoY=874
				ab_RT_Vx_X_0=3441
				ab_RT_Vx_Y_0=870
				ab_RT_Vx_X_1=3451
				ab_RT_Vx_Y_1=869
				ab_RT_Vx_X_2=3450
				ab_RT_Vx_Y_2=877
				ab_RT_Vx_X_3=3441
				ab_RT_Vx_Y_3=878
				ab_RT_Vx_X_4=3441
				ab_RT_Vx_Y_4=870
		STR_VAR ab_RT_Name=~Dragon3~
				ab_RT_Rbcs=~BPsiege3~
	END
	LAUNCH_PATCH_FUNCTION ADD_AREA_REGION_TRIGGER
		INT_VAR ab_RT_BbLX=4782
				ab_RT_BbLY=1078
				ab_RT_BbHX=4792
				ab_RT_BbHY=1086
				ab_RT_VxPr=5
				ab_RT_Itxt=0xffffffff
				ab_RT_TSet=1
				ab_RT_LPoX=4787
				ab_RT_LPoY=1082
				ab_RT_Vx_X_0=4789
				ab_RT_Vx_Y_0=1077
				ab_RT_Vx_X_1=4782
				ab_RT_Vx_Y_1=1079
				ab_RT_Vx_X_2=4784
				ab_RT_Vx_Y_2=1086
				ab_RT_Vx_X_3=4792
				ab_RT_Vx_Y_3=1085
				ab_RT_Vx_X_4=4789
				ab_RT_Vx_Y_4=1077
		STR_VAR ab_RT_Name=~Dragon4~
				ab_RT_Rbcs=~BPsiege4~
	END
	LAUNCH_PATCH_FUNCTION ADD_AREA_REGION_TRIGGER
		INT_VAR ab_RT_BbLX=3878
				ab_RT_BbLY=1941
				ab_RT_BbHX=3890
				ab_RT_BbHY=1950
				ab_RT_VxPr=5
				ab_RT_Itxt=0xffffffff
				ab_RT_TSet=1
				ab_RT_LPoX=3884
				ab_RT_LPoY=1945
				ab_RT_Vx_X_0=3888
				ab_RT_Vx_Y_0=1940
				ab_RT_Vx_X_1=3878
				ab_RT_Vx_Y_1=1941
				ab_RT_Vx_X_2=3880
				ab_RT_Vx_Y_2=1950
				ab_RT_Vx_X_3=3890
				ab_RT_Vx_Y_3=1950
				ab_RT_Vx_X_4=3888
				ab_RT_Vx_Y_4=1940
		STR_VAR ab_RT_Name=~Dragon5~
				ab_RT_Rbcs=~BPsiege5~
	END
	LAUNCH_PATCH_FUNCTION ADD_AREA_REGION_TRIGGER
		INT_VAR ab_RT_BbLX=1778
				ab_RT_BbLY=1774
				ab_RT_BbHX=1791
				ab_RT_BbHY=1782
				ab_RT_VxPr=5
				ab_RT_Itxt=0xffffffff
				ab_RT_TSet=1
				ab_RT_LPoX=1784
				ab_RT_LPoY=1778
				ab_RT_Vx_X_0=1788
				ab_RT_Vx_Y_0=1773
				ab_RT_Vx_X_1=1778
				ab_RT_Vx_Y_1=1774
				ab_RT_Vx_X_2=1781
				ab_RT_Vx_Y_2=1782
				ab_RT_Vx_X_3=1791
				ab_RT_Vx_Y_3=1780
				ab_RT_Vx_X_4=1788
				ab_RT_Vx_Y_4=1773
		STR_VAR ab_RT_Name=~Dragon6~
				ab_RT_Rbcs=~BPsiege6~
	END
	LAUNCH_PATCH_FUNCTION ADD_AREA_REGION_TRIGGER
		INT_VAR ab_RT_BbLX=2127
				ab_RT_BbLY=1728
				ab_RT_BbHX=2137
				ab_RT_BbHY=1735
				ab_RT_VxPr=5
				ab_RT_Itxt=0xffffffff
				ab_RT_TSet=1
				ab_RT_LPoX=2132
				ab_RT_LPoY=1731
				ab_RT_Vx_X_0=2135
				ab_RT_Vx_Y_0=1727
				ab_RT_Vx_X_1=2127
				ab_RT_Vx_Y_1=1728
				ab_RT_Vx_X_2=2130
				ab_RT_Vx_Y_2=1735
				ab_RT_Vx_X_3=2137
				ab_RT_Vx_Y_3=1734
				ab_RT_Vx_X_4=2135
				ab_RT_Vx_Y_4=1727
		STR_VAR ab_RT_Name=~Dragon7~
				ab_RT_Rbcs=~BPsiege7~
	END
	LAUNCH_PATCH_FUNCTION ADD_AREA_REGION_TRIGGER
		INT_VAR ab_RT_BbLX=2156
				ab_RT_BbLY=3380
				ab_RT_BbHX=2167
				ab_RT_BbHY=3391
				ab_RT_VxPr=5
				ab_RT_Itxt=0xffffffff
				ab_RT_TSet=1
				ab_RT_LPoX=2161
				ab_RT_LPoY=3385
				ab_RT_Vx_X_0=2164
				ab_RT_Vx_Y_0=3380
				ab_RT_Vx_X_1=2156
				ab_RT_Vx_Y_1=3380
				ab_RT_Vx_X_2=2157
				ab_RT_Vx_Y_2=3391
				ab_RT_Vx_X_3=2167
				ab_RT_Vx_Y_3=3388
				ab_RT_Vx_X_4=2164
				ab_RT_Vx_Y_4=3380
		STR_VAR ab_RT_Name=~Dragon8~
				ab_RT_Rbcs=~BPsiege8~
	END
	LAUNCH_PATCH_FUNCTION ADD_AREA_REGION_TRIGGER
		INT_VAR ab_RT_BbLX=3372
				ab_RT_BbLY=2737
				ab_RT_BbHX=3382
				ab_RT_BbHY=2746
				ab_RT_VxPr=5
				ab_RT_Itxt=0xffffffff
				ab_RT_TSet=1
				ab_RT_LPoX=3377
				ab_RT_LPoY=2741
				ab_RT_Vx_X_0=3380
				ab_RT_Vx_Y_0=2737
				ab_RT_Vx_X_1=3372
				ab_RT_Vx_Y_1=2737
				ab_RT_Vx_X_2=3374
				ab_RT_Vx_Y_2=2746
				ab_RT_Vx_X_3=3382
				ab_RT_Vx_Y_3=2744
				ab_RT_Vx_X_4=3380
				ab_RT_Vx_Y_4=2737
		STR_VAR ab_RT_Name=~Dragon9~
				ab_RT_Rbcs=~BPsiege9~
	END
	LAUNCH_PATCH_FUNCTION ADD_AREA_REGION_TRIGGER
		INT_VAR ab_RT_BbLX=932
				ab_RT_BbLY=2630
				ab_RT_BbHX=1071
				ab_RT_BbHY=2724
				ab_RT_VxPr=5
				ab_RT_Itxt=0xffffffff
				ab_RT_TSet=1
				ab_RT_LPoX=1001
				ab_RT_LPoY=2677
				ab_RT_Vx_X_0=1041
				ab_RT_Vx_Y_0=2629
				ab_RT_Vx_X_1=1071
				ab_RT_Vx_Y_1=2675
				ab_RT_Vx_X_2=962
				ab_RT_Vx_Y_2=2724
				ab_RT_Vx_X_3=932
				ab_RT_Vx_Y_3=2676
				ab_RT_Vx_X_4=1041
				ab_RT_Vx_Y_4=2629
		STR_VAR ab_RT_Name=~Scene5~
				ab_RT_Rbcs=~SUSCENE5~
	END
BUT_ONLY

//dragon
COPY ~BPv180/SULDAN/BPSULDRA.CRE~ ~override~
COMPILE ~BPv180/SULDAN/BPSULDRA.BAF~

//bombing
COMPILE ~BPv180/SULDAN/COMPILE~ USING ~BPv180/LANGUAGE/%s/BPSIEGE0.tra~

//enable area script for ar2811
COPY_EXISTING ~ar2811.are~ ~override/ar2811.are~
	READ_ASCII %AREA_SCRIPT% scr11
	PATCH_IF NOT FILE_EXISTS_IN_GAME ~%scr11%.bcs~ BEGIN
		SPRINT scr11 ~AR2811~
		WRITE_ASCII %AREA_SCRIPT% ~AR2811~ #8
	END
BUT_ONLY

//other scripts: spawns
EXTEND_TOP ~AR2800.BCS~ ~BPv180/SULDAN/EXTEND/tAR2800.BCS~	//all have OnCreation condition and continue()
EXTEND_TOP ~AR2801.BCS~ ~BPv180/SULDAN/EXTEND/tAR2801.BCS~
EXTEND_TOP ~AR2802.BCS~ ~BPv180/SULDAN/EXTEND/tAR2802.BCS~
EXTEND_TOP ~AR2803.BCS~ ~BPv180/SULDAN/EXTEND/tAR2803.BCS~
EXTEND_TOP ~%scr11%.BCS~ ~BPv180/SULDAN/EXTEND/tAR2811.BAF~	//it will work like compile if AR2811.BCS does not exist

//other scripts
EXTEND_BOTTOM ~AR2807.BCS~ ~BPv180/SULDAN/EXTEND/tAR2807.BAF~	//red dragon arrives after black's dead
EXTEND_BOTTOM ~%scr11%.BCS~ ~BPv180/SULDAN/EXTEND/AR2811.BAF~

Attached Files

•  SULDAN.rar   8.15K   318 downloads

Edited by Turambar, 10 October 2010 - 12:23 PM.

[Miloch]

I'll work on Improved Suldanesselar and those other components now, which apparently need to be fixed. Have you done any others a part from the Crypt king and shadow lord?

No, still working on finishing the main component, so feel free to fix any other subcomponents.

[Turambar]

I found the following comments in the Spellhold component; should I consider them, and add the items only if the difficulty is high enough?
//Adds treasure pile BP_LittleHelp (Spellhold Relief Fund)
//I should deactivate this if the party is on the EASY/EASIEST setting: Global("BP_HardRoad","GLOBAL",2)

Another question is, can I use OnCreation() or is it better to use an area variable?
I know that I have to put OnCreation() blocks on top, and every block I extend top should have Continue(), but if I do this, can I do it?

[Miloch]

I found the following comments in the Spellhold component; should I consider them, and add the items only if the difficulty is high enough?

I guess so. It sounds like it should be the other way around (add free loot only if the difficulty is easy/easiest) but maybe not.

I know that I have to put OnCreation() blocks on top, and every block I extend top should have Continue(), but if I do this, can I do it?

Yes, but an area variable is probably safer, in case some mod later EXTEND_TOPs the area script.

[Turambar]

I guess so. It sounds like it should be the other way around (add free loot only if the difficulty is easy/easiest) but maybe not.

I think that, if the difficulty is medium or more, the inventary is stolen, and you need some non-magical items until you find it

Yes, but an area variable is probably safer, in case some mod later EXTEND_TOPs the area script.

Ok, I'll use that; anyway, noone should extend_top unless he is only adding blocks with continue()

So, I'll put it on top, using an area variable, and the Continue() action (which everyone should use if he extends_top)

Edited by Turambar, 15 October 2010 - 01:13 AM.

[Turambar]

The Spellhold component should be ready.
I've tested it a bit and it should work, but I haven't completely tested it.
The main corrections were:
- Using the area patch instead of copying it
- changed some replace_bcs_block with replace_textually
- turned some EXTEND_TOPs into E_B
- Added Continue() to the remaining E_Ts

There is one .tra file that has to be added to the Language\%s folder; it's called bAR1515..tra and its content is:
English:

@0 = ~We only have a couple minutes' time to grab our gear. We should move quickly~

Italian:

@0 = ~Abbiamo solo pochi minuti per riprenderci i nostri oggetti. Dobbiamo muoverci in fretta~

This is the code:

////////////////////////SPELLHOLD//////////////////////////////

BEGIN @376

COPY ~BPv180/SPELLHD/COPY~         ~override~

COMPILE ~BPv180/SPELLHD/COMPILE~

//Adds treasure pile BP_LittleHelp (Spellhold Relief Fund)
COPY_EXISTING ~AR0012.are~ ~override~
	READ_SHORT 0x74 num
	num += 1
	LAUNCH_PATCH_FUNCTION fj_are_structure
		INT_VAR
		fj_type        = 4 //pile
		fj_loc_x       = 1380
		fj_loc_y       = 1099
		fj_box_left    = 1331
		fj_box_top     = 1058
		fj_box_right   = 1380
		fj_box_bottom  = 1104
		fj_trap_loc_x  = 0
		fj_trap_loc_y  = 0
		fj_vertex_0    = 1368 + (1099 << 16)
		fj_vertex_1    = 1361 + (1104 << 16)
		fj_vertex_2    = 1352 + (1104 << 16)
		fj_vertex_3    = 1342 + (1101 << 16)
		fj_vertex_4    = 1336 + (1095 << 16)
		fj_vertex_5    = 1331 + (1087 << 16)
		fj_vertex_6    = 1331 + (1078 << 16)
		fj_vertex_7    = 1334 + (1070 << 16)
		fj_vertex_8    = 1339 + (1063 << 16)
		fj_vertex_9    = 1347 + (1058 << 16)
		fj_vertex_10   = 1355 + (1057 << 16)
		fj_vertex_11   = 1366 + (1058 << 16)
		fj_vertex_12   = 1373 + (1064 << 16)
		fj_vertex_13   = 1378 + (1070 << 16)
		fj_vertex_14   = 1380 + (1080 << 16)
		fj_vertex_15   = 1378 + (1090 << 16)
		fj_vertex_16   = 1374 + (1096 << 16)
		fj_vertex_17   = 1368 + (1099 << 16)
		STR_VAR
		fj_structure_type = container
		fj_name           = ~BP_LittleHelp~
	END
BUT_ONLY

EXTEND_TOP ~AR0012.BCS~ ~BPv180/SPELLHD/BAF/tar0012.baf~		//Continue()_d OnCreation() block
EXTEND_TOP ~AR1506.BCS~ ~BPv180/SPELLHD/BAF/tar1506.baf~		//continue()_d

EXTEND_BOTTOM ~AR1512.BCS~ ~BPv180/SPELLHD/BAF/ar1512.baf~
EXTEND_BOTTOM ~AR1513.BCS~ ~BPv180/SPELLHD/BAF/ar1513.baf~

COPY_EXISTING ~AR1515.BCS~      ~override~
	DECOMPILE_BCS_TO_BAF
		REPLACE_TEXTUALLY ~SetGlobal("speakWhenLonkDead","GLOBAL",1)~   ~SetGlobal("speakWhenLonkDead","GLOBAL",1)
		Wait(1)~
		REPLACE_TEXTUALLY ~Global("AsylumPlot","GLOBAL",53)~   ~Global("BP_HardRoad","GLOBAL",2)
		Global("AsylumPlot","GLOBAL",53)~
	COMPILE_BAF_TO_BCS 
BUT_ONLY_IF_IT_CHANGES
EXTEND_TOP ~AR1515.BCS~      ~BPv180/SPELLHD/BAF/tAR1515.BAF~
EXTEND_BOTTOM ~AR1515.BCS~        ~BPv180/SPELLHD/BAF/bAR1515.BAF~

COPY_EXISTING ~PPJON.BCS~      ~override~
	DECOMPILE_BCS_TO_BAF
		REPLACE_TEXTUALLY ~Allegiance(Myself,ENEMY)~   ~OR(2)
		Allegiance(Myself,ENEMY)
		AttackedBy([GOODCUTOFF],DEFAULT)~
		REPLACE_TEXTUALLY ~ Global("AsylumPlot","GLOBAL",20)~   ~ Global("AsylumPlot","GLOBAL",20)
	Global("BP_HardRoad","GLOBAL",1)
THEN
	RESPONSE #100
		ClearAllActions()
		StartCutSceneMode()
		StartCutScene("cut41gbp")
END

IF
	Global("AsylumPlot","GLOBAL",20)~
	COMPILE_BAF_TO_BCS 
BUT_ONLY_IF_IT_CHANGES

COPY_EXISTING ~PPSPLIT.BCS~     ~override~
  DECOMPILE_BCS_TO_BAF
    REPLACE_TEXTUALLY ~CreateCreature("umbhul01",\[1055.950\],0)~ ~CreateCreature("BPUMBER",[1055.950],0)~
  COMPILE_BAF_TO_BCS
BUT_ONLY_IF_IT_CHANGES

COPY ~BPv180/SPELLHD/AUTO/BPGOODYS.CRE~      ~override/BPGOODYS.CRE~

COPY ~BPv180/SPELLHD/AUTO/spedwin.spl~       ~override/spedwin.spl~

COPY ~BPv180/SPELLHD/AUTO/spnalia.spl~       ~override/spnalia.spl~

ACTION_IF FILE_EXISTS ~data/TDD-RULE.bif~ THEN BEGIN
  COPY ~BPv180/SPELLHD/AUTO/sprobil.spl~       ~override/sprobil.spl~
  COPY ~BPv180/SPELLHD/AUTO/spshart.spl~       ~override/spshart.spl~
END

ACTION_IF FILE_EXISTS ~data/TS-RULE.bif~ THEN BEGIN
  COPY ~BPv180/SPELLHD/AUTO/spkachi.spl~       ~override/spkachi.spl~
  COPY ~BPv180/SPELLHD/AUTO/spsime1.spl~       ~override/spsime1.spl~
  COPY ~BPv180/SPELLHD/AUTO/spsime2.spl~       ~override/spsime2.spl~
  COPY ~BPv180/SPELLHD/AUTO/spvalyg.spl~       ~override/spvalyg.spl~
END

ACTION_IF FILE_EXISTS ~data/SOS-RULE.bif~ THEN BEGIN
  COPY ~BPv180/SPELLHD/AUTO/spselen.spl~       ~override/spselen.spl~
END

The BPv180/LIB folder must contain the fj_area_structure PF:  fj_are_structure.tpp   46.15K   370 downloads
And here's the new SPELLHD folder:  SPELLHD.rar   19.24K   320 downloads

Next, I'll have a look at the Wand of Orcus.
But I've just noticed a COPY ar3020.wed from the orcus folder.
From what I've seen, the only difference is that in the vanilla one the verticles are in the last part of the file, whereas the modded version has the polygons in the end.
In that case, do I need to copy that file?
What do I have to do?

Edited by Turambar, 22 January 2011 - 06:58 AM.

[Miloch]

But I've just noticed a COPY ar3020.wed from the orcus folder. From what I've seen, the only difference is that in the vanilla one the verticles are in the last part of the file, whereas the modded version has the polygons in the end. In that case, do I need to copy that file? What do I have to do?

If there are no differences except superficial ones, you shouldn't have to do anything with it. Try it without it and see if it works or if a patch is necessary. There are at least a few .are and .wed files like that in the subcomponents that will probably need to get patched.