Jump to content

Add projectiles


Demivrgvs

Recommended Posts

I used ADD_PROJECTILE ~Item_rev\itm\GESBOW.PRO~ to change the arrows fired by gesen bow but if my mod is installed before ADpack (which adds many new projectiles in the same way) some spells get screwed up because of the "number" associated to projectiles.

 

Ex:

- if ADpack get installed before my mod, Flame Strike uses the new ADFLAME.pro (29X)

- if i install my mod and then ADpack flamstrike uses ADPROEVIL.pro (30X) because my new .pro "takes" the 29X slot

 

Is there a way to avoid it or install order is the only solution? Fixpack adds cddetevl.pro but for some reason it doesn't create incompatibilities with ADpack...why?

Link to comment

ADD_PROJECTILE creates a variable with the number of your added projectile. You should use the variable instead of the static value (e.g., if ADpack adds a 299 projectile, the variable of your projectile would be 300).

 

I believe the variable name is the same as the name of your projectile (GESBOW in your case). So try writing %GESBOW% instead of 299. You can check the WeiDU read me for more information.

Link to comment

You want to assign the projectile at the time the mod is installed, and not with the spell editor, because as you've observed it uses the projectile slot number and not the projectile name.

 

Sample code:

 

// Adding Projectiles

ADD_PROJECTILE ~DruidSor/PROs/CA#DBE.pro~
ADD_PROJECTILE ~DruidSor/PROs/CA#FCEXP.pro~
ADD_PROJECTILE ~DruidSor/PROs/CA#FCFIR.pro~
ADD_PROJECTILE ~DruidSor/PROs/CA#FCMET.pro~
ADD_PROJECTILE ~DruidSor/PROs/CA#TCICE.pro~
ADD_PROJECTILE ~DruidSor/PROs/CA#UOM.pro~
ADD_PROJECTILE ~DruidSor/PROs/CA#WAVE.pro~
ADD_PROJECTILE ~DruidSor/PROs/CA#BL.pro~
ADD_PROJECTILE ~DruidSor/PROs/CA#RMBA.pro~

// Copying the spells over
COPY	~DruidSor/SPLs/CA#DSWS.spl~	~override/CA#DSWS.spl~
	SAY NAME1 @200 // spell name
	SAY NAME2 @200 // spell name
	SAY UNIDENTIFIED_DESC @201 // spell description
	WRITE_SHORT	0x98 ~%CA#WAVE%~ // assigning projectile

COPY	~DruidSor/SPLs/CA#DSDBE.spl~	~override/CA#DSDBE.spl~
	SAY NAME1 @275
	SAY NAME2 @275
	SAY UNIDENTIFIED_DESC @276
	WRITE_SHORT	0x98 ~%CA#DBE%~

 

You may need to look a bit more at the IESDP if your spells have multiple extended headers. I haven't worked with spells like that yet so haven't looked into it yet.

Link to comment

Hah, I actually read the original post now.

 

I'm not sure what the best way to tackle this is. I'd suggest just recommending that players install ADpack *prior* to installing your mod (or not install it at all). This is probably the only surefire solution that doesn't involve picking some arbitrary projectile value and hoping nobody else comes along and uses it too (although, I'm not sure from your post exactly why the behavior is different -- even if ADpack isn't using ADD_PROJECTILE correctly, flame strike would still be using 29X).

Link to comment

If there are multiple mods that add custom projectiles, and your modded spell/weapon uses a custom projectile then assigning the projectile using the spell editor (DLTCEP or NI) is actually assigning a projectile slot number. Changing the install order will mean that your custom projectile is no longer in the same projectile slot. Therefore, its best if you patch the projectile in with WeiDU and not try to assign it with the spell/item editor.

 

 

In the case of Flamestrike, it sounds like ADPack is changing it to use a custom projectile. The old flamestrike projectile should still be there however, but if you want to be sure to use the custom projectile for Flamestrike from ADPack, then be sure to ADD_PROJECTILE ~Mymod/PRO/ADFLAME.pro~ and patch it on as I've described above. For even better compatibility, rename ADFLAME.pro and any of the subfiles referenced by it (be sure to open ADFLAME.pro up in DLTCEP or NI and see if it uses any custom spells, sounds, bams, vvcs, secondary projectiles) to your own naming scheme and include all the subfiles as things installed by your mod.

Link to comment

Since he's changing GESBOW and mentions that Flame Strike is correct (when ADpack is installed first), and then it changes (completely unrelated to his projectile, it seems) if ADpack is installed last, I don't think that's the issue here (he wouldn't be writing 29x on one pass and 30x on the next if it were simply that his spell projectiles weren't being assigned at install-time -- it'd still be 29x regardless of when ADpack was installed if that was the case).

 

I think he's saying that installing his mod first screws up ADpack's projectiles, but as written, I can't quite figure it out.

Link to comment

I'm sure there is (likely 32767 at most, but I suspect much smaller). Avenger will know.

 

WeiDU isn't coded to recognize any limit as far as I remember, so it should faithfully go as high as is possible (either around 65536 or from 2 to 4 billion, depending on OCaml type sizes). I'm pretty sure the game would just crash if you went too high.

Link to comment

Thank you for your time and sorry if i weren't clear.

Yes ADPack changes Flame Strike by giving it a new custom projectile and doesn't change the old "Flame Strike".pro. Problem is that when you add a projectile it take the first free slot (and a number is assigned to the .pro accordingly)...therefore if ADPack is installed first, ADXXXX.Pros use slots/numbers 29X-30X but if i install my mod first i have my GESBOW.PRO and CFBATTO.PRO taking two slots (for example 264 and 270). If ADFLAME.PRO was projectile number 299 it now becomes something different, like projectile 310, but the spell still use 299 (which obviously isn't intended).

 

But Fixpack adds a new projectile and it doesn't screws the numbers assigned to ADxxx.PROs so there must be a way to avoid incompatibility i think.

Link to comment

Just my 2c but have you checked the Fixpack code for how do go about this?

 

My basic understanding of this would be they use some Weidu Ninjery to READ the file and then create their entries based on not overwriting existing ones. So it wouldn't matter what was installed in what order...as their install code is READing the file as it stands at install.

 

Pardon me if that made no sense at all.

Link to comment
Thank you for your time and sorry if i weren't clear.

Yes ADPack changes Flame Strike by giving it a new custom projectile and doesn't change the old "Flame Strike".pro. Problem is that when you add a projectile it take the first free slot (and a number is assigned to the .pro accordingly)...therefore if ADPack is installed first, ADXXXX.Pros use slots/numbers 29X-30X but if i install my mod first i have my GESBOW.PRO and CFBATTO.PRO taking two slots (for example 264 and 270). If ADFLAME.PRO was projectile number 299 it now becomes something different, like projectile 310, but the spell still use 299 (which obviously isn't intended).

 

But Fixpack adds a new projectile and it doesn't screws the numbers assigned to ADxxx.PROs so there must be a way to avoid incompatibility i think.

Then yeah, devSin's answer is the way to go. When you ADD_PROJ ~foo~, WeiDU dets a %foo% variable which you can use in your spells to assign them the correct value (regardless of whether it's actually 299, 305, etc.). Caedwyr's code is a good example of this--he adds the CA#WAVE projectile, and then assigns it to CA#DSWS.spl. This way the spell will always use the CA#WAVE projectile, no matter where it actually turns up in the list.

Link to comment

No, you need a loop to walk through each ability and set the projectile (every ability defines its own projectile).

 

You'd want one of the more compatible (more compatible-looking at least) renditions of (note that I'm just guessing at the offsets; I've been on vacation for a few months):

READ_LONG 0x64 ao
FOR (READ_SHORT 0x68 na; na; na -= 0x1) BEGIN
 WRITE_SHORT ao + 0x26 MY_PRO
 ao += 0x28
END

Keep in mind that when working with extended structures (like spell and item abilities) you shouldn't ever use absolute offsets in your writes (your WRITE_SHORT 0x98 could conceivably fail if somebody else's mod deleted the abilities and effects for whatever reason). For items and spells, if the offset is greater than 0x72, you'd want to look at reading the structure offset (0x64 for abilities and 0x6a for effects IIRC) and then writing into the structure from that offset (as with 'ao + 0x26' in the above code).

 

When in doubt, find the corresponding code from the fixpack and copy and modify it for your own use! :)

Link to comment

Archived

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

×
×
  • Create New...