Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.
Name:
Email:
Subject:
Message icon:

Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What color is grass?:
What is the seventh word in this sentence?:
What is five minus two (use the full word)?:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: Miloch
« on: March 12, 2011, 03:34:53 AM »

For what it's worth, a full BWP with v228.12 didn't seem to install any differently than with v228.00. I'll wait for the v229 before releasing the next L1NPCs, as it probably won't work without it.
Posted by: the bigg
« on: March 11, 2011, 03:35:06 PM »

Thanks for your test. MODDER slows down a lot the installer (a file access for all calls to CreateCreature, *SpellRES*(), *Item*(), ...) and reports about 90% of false positives (or bugs introduced by another mod) on BWP.
Posted by: Miloch
« on: March 11, 2011, 02:56:49 PM »

Both mods seem to install fine on Tutu and BWP with v228.12. Though I found out the hard way it is probably pretty stupid to leave MODDER enabled when testing on BWP.
Posted by: the bigg
« on: March 11, 2011, 10:29:42 AM »

L1NPCs installing correctly is cause to assume that all DO_THIS_TO_CRE function properly (and Gen1e above reported that this macro doesn't barf on the known-broken D0QP).
Posted by: Miloch
« on: March 11, 2011, 10:26:17 AM »

Should be done in a few hours. I'm not going to bother with BWP diffs then, if you don't need them. One BWP eats up enough space.
Posted by: the bigg
« on: March 11, 2011, 03:59:40 AM »

Any update on your testing? I think Aurora + L1NPCs would be enough, no need for a full BiG.
Posted by: the bigg
« on: March 08, 2011, 04:51:37 PM »

Done.
Posted by: Miloch
« on: March 08, 2011, 03:52:01 PM »

I guess I could add do_reindex and do_eff, which default at 1 but can be set to 0 to skip the relevant function
Cool. If you want to push a new beta with that, I'll run it on L1NPCs and Aurora (maybe even a full BWP if I get the time/motivation).
Posted by: Wisp
« on: March 07, 2011, 04:37:14 AM »

Was hdragsil corrupted by some mod (Quest Pack or something)? Because the vanilla version is fine after running the code I posted, even without validity/reindexing.

Do you have a vanilla example of a 'zeroed out cre'? I'll admit, I'm not quite sure why zeroing out some offsets is a good idea (I think it was a Taimon utility that did this - I'm assuming he had a good reason for it).
QP overwrites with a cre with a zeroed offset.
Taimon's code fixed zeroed offsets, if I'm not mistaken.
Zeroing offsets is a stupid thing to do and is hopefully not done on purpose.
Posted by: the bigg
« on: March 07, 2011, 03:57:05 AM »

For now it always run FJ_CRE_REINDEX and FJ_CRE_EFF_Vx. I guess I could add do_reindex and do_eff, which default at 1 but can be set to 0 to skip the relevant function:

Code: [Select]
diff --git a/src/tph/include/fj_cre_validity.tpa b/src/tph/include/fj_cre_validity.tpa
index d61cb81..dfa71fd 100755
--- a/src/tph/include/fj_cre_validity.tpa
+++ b/src/tph/include/fj_cre_validity.tpa
@@ -1,4 +1,5 @@
-DEFINE_PATCH_FUNCTION ~FJ_CRE_VALIDITY~ INT_VAR do_message = 0 RET valid BEGIN
+DEFINE_PATCH_FUNCTION ~FJ_CRE_VALIDITY~ RET valid BEGIN
+  SET do_message = IS_AN_INT do_message ? do_message : 0
   SPRINT m1 ~is corrupt~
   SPRINT m2 ~below minimum length~
   SPRINT m3 ~header misplaced~
@@ -52,6 +53,8 @@ DEFINE_PATCH_FUNCTION ~FJ_CRE_VALIDITY~ INT_VAR do_message = 0 RET valid BEGIN
 END
 
 DEFINE_PATCH_FUNCTION ~FJ_CRE_REINDEX~ BEGIN
+  SET do_eff = IS_AN_INT do_eff ? do_eff : 1
+  SET do_reindex = IS_AN_INT do_reindex ? do_reindex : 1
   fv = 0
   kso = 0x2d4
   ksc = 0
@@ -76,12 +79,13 @@ DEFINE_PATCH_FUNCTION ~FJ_CRE_REINDEX~ BEGIN
   SPRINT il fail
   SPRINT el fail
   READ_BYTE 0x33 fv //EFF version
-  PATCH_IF (fv = 0) AND NOT (FILE_EXISTS_IN_GAME ~ar0125.are~) BEGIN
+  PATCH_IF (fv = 0) AND NOT (FILE_EXISTS_IN_GAME ~ar0125.are~) && do_eff BEGIN
     LAUNCH_PATCH_FUNCTION ~FJ_CRE_EFF_V2~ END
   END
-  PATCH_IF (fv != 0) AND (FILE_EXISTS_IN_GAME ~ar0125.are~) BEGIN
+  PATCH_IF (fv != 0) AND (FILE_EXISTS_IN_GAME ~ar0125.are~) && do_eff BEGIN
     LAUNCH_PATCH_FUNCTION ~T-CRE_EFF_V1~ END
   END
+  PATCH_IF do_reindex BEGIN
   READ_BYTE 0x33 fv //EFF version
   PATCH_IF FILE_EXISTS_IN_GAME ~fw0125.are~ BEGIN //Fix buggered Tutu refs
     FOR (s1 = 0xa4; s1 < 0x234; s1 += 0x4) BEGIN
@@ -203,6 +207,7 @@ DEFINE_PATCH_FUNCTION ~FJ_CRE_REINDEX~ BEGIN
     END
   END
   SOURCE_SIZE = off_0 + 0x50
+  END
 END
 
 DEFINE_PATCH_FUNCTION ~FJ_CRE_EFF_V2~ BEGIN
Posted by: Miloch
« on: March 07, 2011, 03:53:45 AM »

That would be great. Ordinarily, I would be fine with not seeing the messages but now (during testing) I'm specifically looking for corrupt/nonstandard CREs. (The problem is, I don't think that will identify CREs hosed *after* modding them, but it's a start at least.)

Come to think of it, I might want to run FJ_CRE_VALIDITY on all CREs after installing something like L1NPCs, with the messaging and *without* reindexing them, just to see if we botched anything. Can we do that or does F_C_V automatically invoke F_C_R no matter what?
Posted by: the bigg
« on: March 07, 2011, 03:39:49 AM »

Incidentally, is there still a way to pass a do_message = 1 to FJ_CRE_VALIDITY if it's called inside another function or macro?
Would this work?
Code: [Select]
--- a/src/tph/include/fj_cre_validity.tpa
+++ b/src/tph/include/fj_cre_validity.tpa
@@ -1,4 +1,5 @@
-DEFINE_PATCH_FUNCTION ~FJ_CRE_VALIDITY~ INT_VAR do_message = 0 RET valid BEGIN
+DEFINE_PATCH_FUNCTION ~FJ_CRE_VALIDITY~ RET valid BEGIN
+  SET do_message = IS_AN_INT do_message ? 0 : do_message
   SPRINT m1 ~is corrupt~
   SPRINT m2 ~below minimum length~
   SPRINT m3 ~header misplaced~

Then you can LPF ~ADD_CRE_ITEM~ INT_VAR do_message = 1 opcode = 53 blah blah blah END and do_message = 1 should still be visible by FJ_CRE_VALIDITY.
Posted by: Miloch
« on: March 07, 2011, 03:03:20 AM »

Was hdragsil corrupted by some mod (Quest Pack or something)? Because the vanilla version is fine after running the code I posted, even without validity/reindexing.

Do you have a vanilla example of a 'zeroed out cre'? I'll admit, I'm not quite sure why zeroing out some offsets is a good idea (I think it was a Taimon utility that did this - I'm assuming he had a good reason for it).

I tested my code on various CREs with differing numbers of effs/items/spell counts etc. and *without* running the validity/reindexing with no issues so far. But it seems tough to find many nonstandard CREs these days, since just about every mod and WeiDU function includes the reindex code.

Incidentally, is there still a way to pass a do_message = 1 to FJ_CRE_VALIDITY if it's called inside another function or macro?
Posted by: GeN1e
« on: March 06, 2011, 09:08:52 PM »

Alright then.

That same poor inconsistent HDRAGSIL, that crashed on me months ago after ADD_CRE_EFFECT. Also trying to add an eff to a zeroed out cre.

1) old macro without offset-check
2) old macro with offset-check
3) new macro with offset-check
4) new macro without offset-check


HDRAGSIL:
1) DLTCEP, crash
2) DLTCEP
3) fine
4) fine

ZEROED:
1) fine
2) DLTCEP
3) DLTCEP
4) fine
Posted by: GeN1e
« on: March 06, 2011, 08:21:22 PM »

Non-standart order - when starting offsets are positioned differently from what is considered 'normal', e.g. effects going before headers in SPL/ITM.

The problem about ADD_CRE_ macro was it's inability to handle properly NSO files, since it was assuming they were SO and didn't bother to check if other offsets were in need of shifting.

As a solution, ADD_CRE began checking for all other offsets, thus allowing for NSO. A slight drawback of it was the possibility of it itself creating NSO from SO, under certain conditions.

Since then, apparently it's been decided somewhere to use a full validity/reindex check before doing the specified patch. Therefore, the offset-checking became obsolete and no longer required to support NSO, but it didn't cease creating NSO on it's own.


PS I suppose some live testing wouldn't hurt then, to be sure.
PPS Curse it, I'll test atm.