Jump to content

Recommended Posts

I get the ever-so-helpful "Patching Failed (COPY) (Invalid_argument("String.sub"))" error when using the ADD_SPELL_EFFECT on spells with multiple effects and multiple headers

This is OCaml telling you the offset for the INSERT_BYTES is out of bounds. :)

 

I think this line

PATCH_IF (___#1effect_index > ___#index1) BEGIN //if ability after current effect

should read

PATCH_IF (___#1effect_index > ___#abil_fx_idx) BEGIN //if ability after current effect

but who knows for sure, what he's doing there.

Share this post


Link to post

Worked like a charm, cheers :). All that routine was doing is updating the indices for the added effects, but obviously was getting thrown off by loop conflicts or something.

 

Hopefully, these can make it into the next WeiDU ;).

Share this post


Link to post
Bugs are fixed in v208. (ADD_ITEM_EFFECT had the same issues.)
Cool. Nice work on v208 btw - much quicker.

 

One little glitch in the macro documentation - I think someone missed a closing italics flag after "they aren't initialized automatically" because the rest of the document is in italics.

Share this post


Link to post
Cool. Nice work on v208 btw - much quicker.

Well, don't thank me. The bigg did all the grammar hacks and cmorgan did an insane amount of testing, to make sure, that these changes don't break any existing mods.

 

One little glitch in the macro documentation - I think someone missed a closing italics flag after "they aren't initialized automatically" because the rest of the document is in italics.

Oh yeah, LaTeX error. :)

I actually never scroll that far down.

Share this post


Link to post
Well, don't thank me. The bigg did all the grammar hacks and cmorgan did an insane amount of testing, to make sure, that these changes don't break any existing mods.
Well, that was for everyone involved. The SPRINT var @123 thing is definitely handy too - saves me an insane amount of hackery. Though I don't know if it lets me do SPRINT var1 @var2 or SPRINT var (@x ^ @y) or SAY offset @(x ^ y) or whatnot, heh... maybe that'll be next :). But at least I think I can avoid using this sort of pseudocode with the existing improvement.

Share this post


Link to post

`SPRINT var @2' is some downright stupid expression introduced by Wes (hint: thanks to that, `SPRINT var foo' gets traified). @(expression) or even @var is not possible without some significant code rewrite, so very unlikely.

Share this post


Link to post

What happened to Wes anyway?

 

Unless he is using an alias, I haven't seen or heard of him in ages.

 

Icen

Share this post


Link to post
What happened to Wes anyway?

 

Unless he is using an alias, I haven't seen or heard of him in ages.

He's single-handedly writing the game engine for JCompton's Broken Hourglass. He also advocates comunity trolling to his students.

Share this post


Link to post

Here is one I just wrote. Many mods that add projectiles via patching often overlook the MISSIE.ids. The purpose of the MISSILE.ids is more modder-related than player related. It simply assigns a name for each projectile in the game, so that you can find your projectile without memorizing the filename and projectl entry. Also, because not all mods append both the PROJECTL and MISSILE IDS files, you may not append the MISSILE.IDS without first updating the last line to be in unison with the PROJECTL.ids

 

And this is what this (small) macro does. This code replaces all non-updated entries in the MISSILE.IDS with "Unnamed", so that you can proceed to patch the MISSILE.IDS along with the PROJECTL.IDS.

 

For those mods that use ADD_PROJECTILE, it is reccommended that you APPEND the MISSILE.ids. You may use this to add entries in the MISSILE.ids

COPY_EXISTING ~MISSILE.ids~ ~override~
COUNT_2DA_ROWS 0 "rowcount"
SET "rowcount" += 1
INNER_ACTION BEGIN
APPEND ~MISSILE.IDS~ ~%rowcount% Cone of Cold~
END
BUT_ONLY_IF_IT_CHANGES

 

And this macro to update the missile.ids before you patch the missile.ids

 

DEFINE_ACTION_MACRO ~update_missile_ids~ BEGIN

COPY_EXISTING ~PROJECTL.ids~ ~override~
COUNT_2DA_ROWS 1 "projectl"
SET projectl += 105 // To account for hardcoded projectiles skipped in PROJECTL.ids
BUT_ONLY_IF_IT_CHANGES

COPY_EXISTING ~MISSILE.ids~ ~override~
COUNT_2DA_ROWS 1 "missile"
WHILE ( missile < projectl ) BEGIN
	SET missile += 1
	INNER_ACTION BEGIN
		APPEND ~MISSILE.IDS~ ~%missile% Unnamed~
	END
END
BUT_ONLY_IF_IT_CHANGES
END

Edited by Galactygon

Share this post


Link to post

Actually, there's an ADD_PROJECTILE command already. Is it not enough?

Share this post


Link to post

The ADD_PROJECTILE command patches the PROJECTL.IDS, but does not patch the MISSILE.IDS. Therefore, mods do not patch the MISSILE.IDS, while still patching the PROJECTILE.IDS.

 

-Galactygon

Share this post


Link to post

OK. Automatic patching for MISSILE.IDS is coming up in WeiDU 209 then - better than doing so manually :fish:

Your code is very much broken though - what value should go into MISSILE.IDS?

Share this post


Link to post
OK. Automatic patching for MISSILE.IDS is coming up in WeiDU 209 then - better than doing so manually :fish:

 

Nice. We still need to run the update macro due to old mods, though.

 

Your code is very much broken though - what value should go into MISSILE.IDS?

Whoops, forgot the +1 increment. Corrected now.

 

-Galactygon

Share this post


Link to post
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...